#репликация_данных — Public Fediverse posts

Площадка недоступна, сроков восстановления нет: как спроектировать DR, который переживёт потерю ключевого ЦОДа

В ночь на 8 октября в Yandex Cloud потеряла электропитание зона доступности ru-central1-b — один из ключевых дата-центров облака. К утру компания сообщила, что работа дата-центра полностью остановлена. Жалобы на сбои начали поступать от пользователей самых разных сервисов: сайтов объявлений вроде «Авито» и «ЦИАН», банков, транспортных порталов, ритейла и других. Утром 9 октября были полностью выведены из строя несколько модулей ещё одного дата-центра Яндекса, в Калуге. На момент подготовки статьи срок восстановления оборудования не назван. Для инженеров это повод ответить на неудобный вопрос: что будет, если площадка, где расположен прод, внезапно выйдет из строя на неопределённое время? Под катом разберём сценарии отказов инфраструктуры, архитектуру восстановления на независимой площадке и посчитаем RPO и RTO на модельном примере из 40 ВМ. Кат

https://habr.com/ru/companies/hstx/articles/1092602/

#резервное_копирование #цод #отказоустойчивость #disaster_recovery #rto #rpo #облачная_инфраструктура #yandex_cloud #репликация_данных #hystax_acura

Абьюзивные отношения с Ceph: почему мы всё ещё не разводимся с ним

«Нам нужен Ceph» — эту фразу хотя бы раз слышал каждый, кто работает с инфраструктурой. И почти всегда за ней следует вопрос: «А нет ли на рынке альтернатив попроще?» Ночные дежурства, CRUSH, поиск инженеров, которые реально умеют его эксплуатировать… Но когда снова нужно серьёзное хранилище — в обсуждении опять появляется он. Разбираемся, почему мы двадцать лет не можем с ним расстаться, хотя иногда очень хочется. Разобраться в причинах

https://habr.com/ru/companies/flant/articles/1068548/

#ceph #cephfs #opensource #crush #rbd #cephfs_в_kubernetes #репликация_данных #ceph_csi_драйвер #storage #deckhouse

Как спроектировать кластер программно-определяемого блочного хранилища, который не подведет через год

SDS-кластер, собранный на глазок и прошедший приёмочные тесты, вполне может проработать полгода без единой жалобы, а потом упереться в стену. Причина обычно в том, что при проектировании никто не подумал об эксплуатации на годы вперёд — не заложили рост по узлам, памяти или сети, и нагрузка уперлась в архитектурный лимит, который без остановки и миграции не раздвинуть. Большинство таких проблем можно предсказать и предотвратить ещё на этапе проектирования — об этом статья: как выбрать архитектуру для кластеров MIND uStor, посчитать ресурсы сервера, спроектировать сеть и настроить кластер так, чтобы он держал нагрузку предсказуемо и переживал отказы без драмы. Материал написан для инженеров, которые проектируют или сопровождают такие кластеры.

https://habr.com/ru/companies/mind_software/articles/1072954/

#SDS #программноопределяемое_хранилище #блочное_хранилище #СХД #MIND_uStor #Erasure_Coding #репликация_данных #capacity_planning #отказоустойчивость #NVMe

Почему шины данных не всегда лучшее решение для синхронизации систем

При миграции из одной корпоративной системы в другую часто встает задача репликации данных. Например, при поэтапной замене ERP по методологии Parallel Running во время опытной эксплуатации пользователи работают в двух системах, которые оперируют идентичным набором данных. Если модели данных сильно отличаются, а при репликации присутствует дополнительная логика, то команды чаще всего пытаются использовать шины данных (например Kafka). При таком подходе требуется самостоятельно реализовать механизмы копирования данных, обработки конфликтов, пересинхронизации, мониторинга и т. д. Все это увеличивает трудозатраты и потенциально может стать источником проблем. В этой статье разберем техническую реализацию репликации данных через шины, ее слабые места, а также альтернативные подходы.

https://habr.com/ru/companies/haulmont/articles/1058574/

#erpсистемы #миграция #миграция_данных #синхронизация #синхронизация_данных #репликация #репликация_данных #parallel_running #erp #шины_данных

Tarantool DataBase и Kafka: событийная архитектура без лишних слоев

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

https://habr.com/ru/companies/vktech/articles/1045344/

#Tarantool #архитектура #отказоустойчивость #cdc #kafka #eventdriven #realtime #интеграция #репликация_данных #vk_tech

«Сто вопросов» взрослому энтерпрайзу: как мигрировать в облако без API

Помните программу «Сто вопросов взрослому», где герою задают прямые и неудобные вопросы, на которые нельзя ответить отговорками? По-моему, это отличный формат и для общения с отделом разработки. Особенно когда приходится защищать перед техлидами нестандартные решения — например, миграцию вообще без использования облачного API. В идеальном мире миграция работает как часы: контроллер подключается к платформе по API, автоматически создает сети, разворачивает машины и переносит данные. В суровой реальности крупного энтерпрайза эта схема часто рушится: целевое облако может быть «самописным» и не иметь нужных методов, либо безопасники отказываются пускать стороннее ПО в закрытый контур. Для работы в условиях таких ограничений мы используем режим Direct2Target (D2T). Это подход, при котором данные передаются напрямую на диски заранее подготовленной ВМ, полностью минуя интеграцию с управляющим слоем облака. В теории концепция звучит изящно, но у инженеров логично возникает скепсис по поводу физики процесса. Я расшифровал техническую сессию с нашего недавнего вебинара . Вопросов под катом, конечно, не сто, но я оставил самую суть — те, что нам чаще всего задают архитекторы: как не утилизировать сеть на 100%, как «наживую» перенести PostgreSQL без потери консистентности, как пробиться через глухой NAT и что делать, если целевая ВМ не завелась. Кат

https://habr.com/ru/companies/hstx/articles/1036298/

#ИТинфраструктура #облачная_миграция #D2T #облачный_API #закрытый_контур #информационная_безопасность #системная_архитектура #миграция_СУБД #репликация_данных #системное_администрирование

Акура-тное приземление. 5 ошибок бэкапа, которые могут стоить вам инфраструктуры

Представьте: вы прыгаете с парашютом, дергаете кольцо, а из ранца вместо купола вылетает записка: «404: Not Found». В ИТ-инфраструктуре бэкап — именно такой парашют. И проблема в том, что 90% инженеров уверены: раз ранец за спиной висит, значит, гравитация им не страшна. Мало кто проверяет его «укладку» (валидацию) и тренирует само приземление (DR). Чаще всего процесс строится либо на слепой вере в собственную память, либо на тотальном доверии древним скриптам, которые DevOps-археолог написал еще пять лет назад. В момент свободного падения времени на исправление конфигов этих скриптов уже не будет. Поэтому под катом — краткая инструкция по «укладке парашюта»: быстро и без воды про классические ошибки и как их обойти. Дернуть кольцо

https://habr.com/ru/companies/hstx/articles/995750/

#бэкап #резервное_копирование #Disaster_Recovery #системное_администрирование #информационная_безопасность #RPO #автоматизация #RTO #отказоустойчивость #репликация_данных

Как реализовать CRDT-структуры в Go для офлайн-режима

Привет, Хабр! Сегодня мы поговорим о том, как справиться с синхронизацией данных в офлайн-режиме так, чтобы не сваливать на пользователя головную боль слияния конфликтов. Вы наверняка замечали, что многие современные приложения — будь то заметки, менеджеры задач или вики-редакторы — позволяют работать оффлайн на нескольких устройствах, а при подключении к сети автоматически объединяют изменения. Задача разработчика в таком случае сделать максимально гладкую синхронизацию одновременно изменённых данных на разных узлах, ideally без участия пользователя в разрешении конфликтов. Классические решения вроде Operational Transformation давно применяются, например, в совместном редактировании документов. Но сегодня я хочу рассказать про другой подход — CRDT . Перейти к разбору CRDT

https://habr.com/ru/companies/otus/articles/956978/

#golang #crdt #распределённые_системы #синхронизация_данных #офлайнсинхронизация #репликация_данных #консистентность_данных

Файловая репликация в СХД АЭРОДИСК ENGINE: для тех, кто устал терять данные по тупым причинам

Данные не ломаются сами по себе — их ломают люди. Уборщица шваброй, приложение, написанное «на отвали», админ в пятничной прострации. Причины разные — результат один: файлов нет, виноватого тоже. Чтобы не восстанавливать инфраструктуру с нуля по скриншотам из Notion, в АЭРОДИСК ENGINE есть файловая репликация. Это не бэкап, это реальное дублирование файлов между хранилищами, которое спасает, когда кто-то опять «просто немного пофиксил в проде». Без костылей, без CLI-гимнастики, без надежды на авось. Настроили — и пусть хоть полсервера ляжет, данные у вас уже есть в другом месте. Разбираемся, как оно устроено, чтобы потом не было «ой, не знал».

https://habr.com/ru/companies/aerodisk/articles/936862/

#аэродиск #схд #репликация_данных

Аварии как опыт. Особенности репликации материализованных представлений в ClickHouse

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

https://habr.com/ru/companies/flant/articles/875510/

#clickhouse #репликация #репликация_данных #materialized_view #материализованные_представления #кластер #повреждения_данных #данные

СОЗДАНИЕ ETL-ДВИЖКА ДЛЯ РЕПЛИКАЦИИ ДАННЫХ ИЗ APACHE HIVE В CLICKHOUSE

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

https://habr.com/ru/articles/874262/

#apache_hive #репликация_данных #python #clickhouse #apache_airflow #spark #jupyterlab #jupyter_notebook