В разработке банковского ПО данному аспекту системы уделяется наибольшее внимание. Часто, описывая отказоустойчивую систему, используют слова: Fault Tolerance, Resilience, Reliability, Stability, DR (disaster recovery). Данная характеристика — суть способность системы продолжать корректно работать при падении одной или нескольких подсистем, от которых она зависит. Я кратко опишу какие подходы могут применяться в данной области и приведу пару примеров.

Данным постом постараюсь описать протокол с помощью которого можно повысить надежность ВЕБ-приложения при возникновении проблем соединения с сервером. Постараюсь описать абстрагируясь от технологий однако в тексте будут приведены примеры серверного Java кода и JavaScript/SmartClient на UI для наглядности описуемого и по причине того что данный протокол был реализован в рамках существующего проекта с использованием данных технологий.

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

Исправляюсь! Теперь понятным языком и с юмором!

Чёрная пятница оказалась воистину чёрной для aмериканского интернет-универмага Kohl's. Все сервера накрылись медным тазом именно в день рождественских распродаж. Привычные 20% годового дохода, добываемые в этот день, обернулись смешным пустяком, а все потому что Боливар не вынес такой нагрузки.

Традиционная архитектура Tomcat + WebLogic + БД облажалась по полной программе! Напрасно бегали по этажам сисадмины, суетились в панике ведущие программисты, а архитекторы выдирали остатки волос… Горлышко бутылки оказалось слишком узким для того, чтобы в него могли протиснуться все потенциальные клиенты и недостаточно эластичным, чтобы за короткое время его можно было успеть расширить. Бутылку разорвало нахрен. И долго еще кровоточили раны, нанесённые ее осколками…

В последние годы требования к приложениям значительно изменились. Десятки серверов, время отклика в несколько секунд, оффлайновое обслуживание, которое могло длиться часами, гигабайты данных — такими были большие приложения буквально несколько лет назад. Сегодня же приложения работают абсолютно на всём, начиная с простых мобильников и заканчивая кластерами из тысячи процессоров. Пользователи ожидают миллисекундного времени отклика и стопроцентного аптайма, в то время как данные выросли до петабайтов.

Первоначально эту нишу занимали крупные инновационные интернет-компании типа Google или Twitter, однако такие требования к приложениям начали всплывать во многих областях индустрии. Финансовые и телекоммуникационные компании первыми начали внедрять новые практики, чтобы удовлетворить новым требованиям, а теперь подтягиваются и остальные.

Новые требования требуют новых технологий. Предыдущие решения делали упор на управляемые сервера и контейнеры. Масштабирование достигалось засчёт покупки более крутых серверов и использования многопоточности. Для добавления новых серверов приходилось применять комплексные, неэффективные и дорогие проприетарные решения.

Однако прогресс не стоит на месте. Архитектура приложений эволюционировала в соответствии с изменившимися требованиями. Приложения, разработанные на основе этой архитектуры, мы называем Реактивными Приложениями. Такая архитектура позволяет программистам создавать событийно-ориентированные, масштабируемые, отказоустойчивые и отзывчивые приложения — приложения, работающие в реальном времени и обеспечивающие хорошее время реакции, основанные на масштабируемом и отказоустойчивом стеке и которые легко развернуть на многоядерных и облачных архитектурах. Эти особенности критически важны для реактивности.

За последние несколько лет в мире IT появилась модная тенденция – использование всего «облачного» для разработки новых продуктов. Публичных облачных провайдеров не так много, самый популярных среди них – Amazon. Однако многие компании не готовы доверять приватные данные кому-либо, при этом хотят хранить их надежно, и поэтому поднимают частные небольшие облачка.

Любое облако состоит из двух основных компонентов: Единой Точки Входа (ЕТВ) и Облачной Магии (ОМ). Рассмотрим облачное хранилище Amazon S3: в роли ЕТВ используется довольно удобный REST API, а Облачную Магию обеспечивают эльфы, работающие на долларах. Компании, желающие разместить в S3 небольшие видеофайлы или базу данных, предварительно считают на калькуляторе сумму, которую они будут платить в месяц при планируемой нагрузке.

Эта статья про другое облачное хранилище, в котором эльфы питаются Духом Свободы, электричеством и еще им нужно немножечко «кокаина».

Называется это хранилище Elliptics.

Некоторое время назад я начал рассказывать на Хабре про Elliptics — наше отказоустойчивое распределенное key-value хранилище (к слову, свободное и распространяемое под GPL-лицензией). Тогда я в общем описал устройство Elliptics: про архитектуру и основные принципы работы, за счет чего достигается надежность системы, как систему можно расширять, и как она ведет себя при сбоях.

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



Сегодня — про сетевую и программную архитектуру Elliptics и некоторые из его особенностей. Также я подробно расскажу про кэш и нашу низкоуровневую библиотеку для локального хранения данных — Eblob.

Понятиям MTTF (Mean Time To Failure — среднее время до отказа) и другим терминам теории надежности посвящено большое количество статей, в том числе на Хабре (см., например, тут). Вместе с тем, редкие публикации «для широкого круга читателей» затрагивают вопросы математической статистики, и уж тем более они не дают ответа на вопрос о принципах расчета надежности электронной аппаратуры по известным характеристикам ее составных элементов.

В последнее время мне довольно много приходится работать с расчетами надежности и рисков, и в этой статье я постараюсь восполнить этот пробел, отталкиваясь от своего предыдущего материала (из цикла о машинном обучении) о пуассоновском случайном процессе и подкрепляя текст вычислениями в Mathcad Express, повторить которые вы сможете скачав этот редактор (подробно о нем тут, обратите внимание, что нужна последняя версия 3.1, как и для цикла по machine learning). Сами маткадовские расчеты лежат здесь (вместе с XPS- копией).

В предыдущей статье мы рассмотрели терминологию и математическую основу расчетов отказоустойчивости различных систем и выяснили, что на практике, когда речь идет об оценках MTTF (Mean Time To Failure — среднего времени до отказа) и других характеристик надежности, в большинстве случаев предполагается, что отказы подчиняются пуассоновской модели. Соответственно, их вероятностное описание основано на экспоненциальном распределении вероятностей.

Этот материал будет посвящен практическим аспектам применения этой модели, причем стоит сразу оговориться, что он широко используется, как в электронике, так и в самых разных областях: например, при оценке рисков в авиационной и атомной отрасли, прогнозирования в автопроме, оценке надежности облачных сервисов в Интернете и т.п. Общим предположением, повторюсь, является гипотеза о постоянстве интенсивности отказов λ, которая, как мы увидели из предыдущей статьи, обратно пропорциональна среднему времени безотказной работы MTTF=1/λ.

Итак, давайте для начала рассмотрим совсем простой пример: устройство, состоящее из двух элементов, для каждого из которых известны интенсивности отказов λ₁ и λ₂. Отказ любого из элементов приводит к отказу устройства в целом. Например, компьютер (условно) можно представить, как систему, состоящую из процессора и материнской платы. Пусть для них среднее время до отказа (MTTF) равны 2 и 3 годам (соответственно, λ₁=1/2 года^-1 и λ₂=1/3 года^-1). Какова будет оценка MTTF для компьютера, в целом? И какова вероятность отказа компьютера через 1 год после начала эксплуатации?

Выражаем благодарность за подготовку статьи Павлу Ковтуну — CEO Mycroft Assistant. Павел больше 12 лет
специализируется в области автоматизации бизнеса и supply chain management.Является автором уникальных методик анализа и принятия решений в SCM, создатель первой инновационной системы управления запасами экспертного уровня.

Выражаем благодарность за подготовку статьи Артему Жуковец — CTO NovaPress Publisher. Проект-победитель конкурса “Герои российских стартапов”

В данной статье рассмотрим архитектуры простых и эффективных KV-хранилищ с использованием цепной репликации (chain replication), которая активно исследуется и успешно применяется в различных системах.

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

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

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

... перебрасывая трафик на другую ноду (реплику), чтобы устранить бездействие, надо построить средства защиты от дребезга и других пограничных ситуаций. Это не сложно. Фокус при организации эффективной работы в том, чтобы знать, когда перевести базу данных в первую позицию, т.е. надо быть в состоянии правильно оценить работоспособность базы данных. Сейчас многие параметры, на которые мы привыкли обращать внимание, — например, загрузка процессора, время ожидания блокировки, частота ошибок, — являются вторичными сигналами. Ни один из этих параметров на самом деле не говорит о способности базы данных к обработке клиентского трафика. Поэтому, если используете их для принятия решения о переключении, можете получить как ложноположительные, так и ложноотрицательные результаты. Наше устройство проверки работоспособности фактически выполняет простые запросы к узлам базы данных и использует данные о выполненных и невыполненных запросах для более точной оценки работоспособности базы данных.

Я обсудила это с другом, и он предположил, что проверки работоспособности должны быть предельно простыми, и что реальный трафик — это лучший критерий для оценки работоспособности процесса.

As many of our readers know, Qrator.Radar is constantly researching global BGP connectivity, as well as regional. Since the Internet stands for “Interconnected Networks,” to ensure the best possible quality and speed the interconnectivity of individual networks should be rich and diverse, with their growth motivated on a sound competitive basis.

The fault-resistance of an internet connection in any given region or country is tied to the number of alternate routes between ASes. Though, as we stated before in our Internet Segments Reliability reports, some paths are obviously more critical compared to the others (for example, the paths to the Tier-1 transit ISPs or autonomous systems hosting authoritative DNS servers), which means that having as many reachable routes as possible is the only viable way to ensure adequate system scalability, stability and robustness.

This time, we are going to have a closer look at the Russian Federation internet segment. There are reasons to keep an eye on that segment: according to the numbers provided by the RIPE database, there are 6183 autonomous systems in Russia, out of 88664 registered worldwide, which stands for 6.87% of total.

This percentage puts Russia on a second place in the world, right after the USA (30.08% of registered ASes) and before Brazil, owning 6.34% of all autonomous systems. Effects of changes in the Russian connectivity could be observed across many other countries dependant on or adjacent to that connectivity, and ultimately by almost any ISP in the world.

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

В прошлой статье мы разобрали теоретические основы реактивной архитектуры. Пришло время поговорить о потоках данных, путях реализации реактивных Erlang/Elixir систем и шаблонах обмена сообщениями в них:

• Request-response
• Request-Chunked Response
• Response with Request
• Publish-subscribe
• Inverted Publish-subscribe
• Task distribution

Анонс

Коллеги, в середине лета я планирую выпустить еще один цикл статей по проектированию систем массового обслуживания: “Эксперимент VTrade” — попытка написать фреймворк для торговых систем. В цикле будет разобрана теория и практика построения биржи, аукциона и магазина. В конце статьи предлагаю проголосовать за наиболее интересные вам темы.

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

Сегодня мы поднимем вопросы развития кодовой базы и проектов в целом.

This report explains how the outage of a single AS can affect the connectivity of the impacted region with the rest of the world, especially when it is the dominant ISP on the market. Internet connectivity at the network level is driven by interaction between autonomous systems (AS’s). As the number of alternate routes between AS’s increases, so goes the fault-resistance and stability of the internet across the network. Although some paths inevitably become more important than others, establishing as many alternate routes as possible is the only viable way to ensure an adequately robust system.

The global connectivity of any AS, regardless of whether it is a minor provider or an international giant, depends on the quantity and quality of its paths to Tier-1 ISPs. Usually, Tier-1 implies an international company offering global IP transit service over connections to other Tier-1 providers. But there is no guarantee that such connectivity will be maintained. Only the market can motivate them to peer with other Tier-1’s to deliver the highest quality service. Is that enough? We explore this question in the IPv6 section below. For many ISPs at all levels, losing connection to just one Tier-1 peer would likely render them unreachable in some parts of the world.

Measuring Internet Reliability

Let’s examine a case where an AS experiences significant network degradation. We want to answer the following question: “How many AS’s in the region would lose connectivity with Tier-1 operators and their global availability along with it?”

Управление ресурсами кластера всегда сложная тема. Как объяснить необходимость настройки ресурсов пода пользователю, который деплоит свои приложения в кластер? Может проще это автоматизировать?

Моя основная работа — это, по большей части, развертывание систем ПО, то есть уйму времени я трачу, пытаясь ответить на такие вот вопросы:

• У разработчика это ПО работает, а у меня нет. Почему?
• Вчера это ПО у меня работало, а сегодня нет. Почему?

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

Поэтому вместо обычных инструментов для отладки вроде gdb у меня есть другой набор инструментов для отладки развертывания. И мой любимый инструмент для борьбы с проблемой типа "Почему это ПО у меня не пашет?" называется strace.