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

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

Привет всем!

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

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

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

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

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

Эта статья основана на наших материалах по консистентности и 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’а.

Здравствуйте, коллеги.

Мы только что отдали в перевод интересную книгу Брендана Бёрнса, рассказывающую о паттернах проектирования для распределенных систем

Кроме того, у нас уже полным ходом идет перевод книги "Mastering Kubernetes" (2-е издание) и готовится к выходу в сентябре авторская книга о Docker, о которой обязательно будет отдельный пост.

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

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

И если в текстовом формате мы не первый раз рассказываем истории из разработки, то теперь решили организовать митап в сентябре вместе с друзьями из DevGAMM, где будем на реальных кейсах разбирать архитектуру в глобальном понимании — от системных решений и приложений до архитектурных паттернов и стилей. И в этот раз мы решили уйти от традиционного стиля «митапов», поэтому — всего 222 отобранных приглашенных, актуальные темы и крутой нетворкинг на митапе (А|а)рхитектура.

А для тех, кто заинтересовался — под катом FAQ и подробности.

Разрабатывая различные приложения, использующие популярную библиотеку Castle Windsor для внедрения зависимостей и Apache Ignite.NET в качестве «ключика», который открывает дверь в «облачные» вычисления, я столкнулся с небольшим неудобством: у меня не было никакой возможности внедрить зависимость в сервис, запускаемый через так называемый Service Grid.

Причина по которой это происходит довольна банальна. Apache Ignite.NET сериализует сервис, отправляет его на один из доступных серверов, где он десериализуется и запускается. Так как этот процесс никаким образом не имеет понятия о Castle Windsor, мы получаем то, что получаем.

Для решения этой проблемы нам необходимо создать плагин для Apache Ignite.NET, который получит контейнер, отвечающий за внедрение зависимостей и предоставить возможность сервису обратиться к нему, для получения того или иного объекта.

Понятие IoT (Internet of Things) давно вошло в лексикон IT-шников. Хотя я и не нашел такого хаба, но надеюсь это скоро будет исправлено :)

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

Введение

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

Приступим.

Анализ

Начинается все очень даже неплохо: