Распределённые системы *

Привет, Хабр!

На этой неделе мы ожидаем из типографии новую книгу по Spring 5:


Среди интересных возможностей Spring 5 отдельного упоминания заслуживает реактивное программирование, о реализации которого в этом фреймворке кратко рассказывает предлагаемая статья Мэтта Рэйбла (Matt Raible). В вышеупомянутой книге реактивные паттерны рассмотрены в главе 11.

Соавтором Мэтта выступил Джош Лонг, автор еще одной отличной книги про Java и Spring, "Java в облаке", вышедшей у нас прошлым летом.

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

Первый сервис в Nomad я запустил в сентябре 2016 года. На данный момент пользуюсь как программист и занимаюсь поддержкой как администратор двух Nomad кластеров — один "домашний" для своих личных проектов (6 микро-виртуалок в Hetzner Cloud и ArubaCloud в 5 разных датацентрах Европы) и второй рабочий (порядка 40 приватных виртуальных и физических серверов в двух датацентрах).

За прошедшее время накопился довольно большой опыт работы с Nomad окружением, в статье опишу встреченные проблемы Nomad и как с ними можно справиться.

Ямальский кочевник делает Continous Delivery инстанса вашего ПО © National Geographic Россия

В этой статье мы смоделируем и исследуем протокол двухфазного коммита с помощью TLA+.

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

Проблема двухфазного коммита

Транзакция проходит через диспетчеры ресурсов (RM). Все RM должны договориться, будет транзакция завершена или прервана.

Менеджер транзакций (TM) принимает окончательное решение: коммит или отмена. Условием для коммита является готовность к коммиту всех RM. В противном случае транзакцию следует отменить.

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

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

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

Привет всем!

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

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

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

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

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

Эта статья основана на наших материалах по консистентности и ACID-гарантиям в распределенных системах.

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

Если 8 и 9 ноября вы будете на конференции Highload++, это отличный повод для встречи. Оба дня на стенде GridGain (А4) будут присутствовать архитекторы и разработчики, которе ответят на любые вопросы про Apache Ignite и GridgGain. Кроме разговоров и стикеров на стенде можно принять участие в небольшом исследовании. Каждый вечер в 18:15 между ответившими на вопросы будут разыграны полезные книги. А также у нас запланированы 1 доклад, 2 митапа и 1 мини-батл.



Присоединяйтесь!

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

Check Point использует стандартный IPSec

Это первое, что нужно знать про Site-to-Site VPN от Check Point. И этот тезис отвечает на один из самых частый вопросов относительно Check Point VPN:

— Можно ли его “подружить” с другими устройствами?
— Да, можно!

Так называемый 3rd party VPN. Поскольку используется стандартный IPSec, то и VPN можно строить с любым устройством, которое поддерживает IPSec. Лично я пробовал строить VPN с Cisco ASA, Cisco Router, D-Link, Mikrotik, StoneGate. Все работает, хотя и есть некоторые особенности. Главное правильно задать все параметры для первой и второй фазы. Поддерживаемые параметры для IPSec соединения:

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

Требования, которые выставляет заказчик — минимальное время данной операции, поскольку чем раньше расхождение будет найдено, тем легче будет устранить его последствия. Задача заметно усложняется тем, что системы находятся в постоянном движении (~ 100 000 транзакций в час) и добиться 0% расхождений не получится.

Прим. перев.: Оригинальная статья была написана техническим писателем из Google, работающим над документацией для Kubernetes (Andrew Chen), и директором по software engineering из SAP (Dominik Tornow). Её цель — доступно и наглядно объяснить основы организации и реализации high availability в Kubernetes. Нам кажется, что у авторов получилось, поэтому мы рады поделиться переводом.



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

Kubernetes — масштабируемый и надёжный движок оркестровки контейнеров. Масштабируемость здесь определяется отзывчивостью в присутствии нагрузки, а надёжность — отзывчивостью в присутствии отказов.

Предисловие

Эта статья является реакцией на статью: Что будет с обработкой ошибок в С++2a. После каждого абзаца у меня появлялся зуд, открывались зарубцованные раны и начинали кровоточить. Может, я принимаю слишком близко к сердцу то, что написано. Но просто хочется выть о той близорукости и безграмотности, что проявляют программисты на С++ в 21 веке. Причем даже не в его начале.

Приступим.

Классификация

Условно все ошибочные ситуации в программе можно разделить на 2 большие группы:

1. Фатальные ошибки.
2. Не фатальные, или ожидаемые ошибки.

В распределенных системах есть ряд фундаментальных проблем: эффективные распределенные транзакции, exactly-once обработка данных, точная синхронизация физических часов. Для решения последней проблемы были изобретены разные виды логических часов.

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

Однако, можно придумать нечто более надежное — Kronos. В статье мы посмотрим на алгоритм учета причинно-следственной связи и его применение для построения Key-Value хранилища с распределенными транзакциями.

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

Наш формат:

1. Выбираем книгу.
2. Определяем часть, которую необходимо прочитать за неделю. Выбираем небольшой объем.
3. В пятницу обсуждаем прочитанное.
4. Читаем в нерабочее время, обсуждаем в рабочее.
5. После окончания книги совместно выбираем следующую.

Что дает:

1. Мотивация на чтение и дочитывание.
2. Развитие скиллов (в том числе на будущее).
3. Выравнивание майндсета и терминологии в команде.
4. Рост доверия.
5. Лишний повод пообщаться.

Одна из недавних книг, которую мы читали — Designing Data-Intensive Applications. Да-да, та самая книга с кабанчиком. И эта книга настолько всем понравилась, что я решил сделать здесь обзор, чтобы большее количество людей ее прочитали.


Карта в исходном качестве

11 сентября в Санкт-Петербурге прошел Java Meetup, полностью посвященный Apache Ignite. Огромное спасибо организаторам за приглашение и возможность рассказать об Open Source от лица разработчика этого самого Open Source. Учитывая позитивную реакцию зала, я решил поделиться презентацией и с теми, кто не смог присутствовать на митапе.

Под катом вас ожидает текстовая версия презентации, полная субъективного восприятия Open Source, как позитивного, так и негативного.

15 сентября в Авито прошёл митап, на котором мы говорили о масштабировании приложений на PostgreSQL. Сегодня я хочу поделиться материалами с него — видеозаписями, презентациями от докладчиков, показать фото. Также под катом публикую разбор вопросов викторины, которую мы проводили здесь, на Хабре, перед митапом. И рассказываю о своих впечатлениях от встречи.

Осталось буквально несколько дней до новой встречи #RuPostgres. Она пройдёт уже в эту субботу, 15 сентября, в офисе Авито. Будем говорить о масштабировании приложений на PostgreSQL. Хорошие новости — у нас немного расширилась программа, и осталось ещё несколько свободных мест для слушателей. Присоединяйтесь. А ещё мои коллеги придумали мини-викторину, посвященную Postgres. Её мы проводим онлайн, поэтому принять участие могут все. Подробности под катом.

Меня зовут Юрий Невиницин, и я занимаюсь системой внутренней статистики в «ОК». Хочу рассказать о том, как 50-терабайтную аналитическую систему реального времени, в которой ежедневно журналируются миллиарды событий, мы переносили с Microsoft SQL на колоночную базу под названием Druid. И заодно вы узнаете несколько рецептов использования Druid’а.