Введение
В мире распределенных систем случаются катастрофические ошибки. Представьте, что вы случайно удалили кучу кластеров из своей инфраструктуры блокчейна. Такие случаи могут привести к ужасным последствиям.
Лучший способ избежать таких неприятностей — это иметь подходящие резервные копии данных. Когда работаешь с блокчейном для предприятий в системах оркестрации контейнеров, наличие резервных копий данных очень важно, особенно при реализации стратегии резервного копирования блокчейна Kubernetes и надежной стратегии резервного копирования системы оркестрации контейнеров.
Сочетание этих технологий создает мощную и очень безопасную платформу для обработки транзакций блокчейна. Сама структура — это решение с открытым исходным кодом, которое управляется сообществом и предлагает платформу для всех реализаций, связанных с распределенным реестром.
Эта структура имеет большие преимущества, такие как высокая производительность и масштабируемость. Она обеспечивает высокую степень доверия между участниками с известными идентичностями и богатые возможности запросов по неизменяемому реестру.
Это руководство предлагает полное руководство по резервному копированию и восстановлению блокчейна, защите и восстановлению данных в сетях блокчейна, которые работают в контейнерных средах без проблем, включая сценарии аварийного восстановления Hyperledger Fabric.
Понимание того, зачем нужны резервы данных, — это основа всего процесса.
Почему резервы данных так важны
Создание резервов данных — это не просто опция, а обязательное требование из-за нескольких важных причин.
Надежность системы
Наличие резервных копий данных позволяет командам работать с большей уверенностью. При использовании облачного хранилища для резервного копирования дополнительный уровень безопасности предотвращает различные формы потери данных, вызванные:
- •Природные бедствия
- •Человеческая ошибка
- •Злонамеренные атаки
Например, если при перезапуске или сбое подсистемы возникают ошибки в настройке правильного пути монтирования для приложения в спецификации развертывания, без надлежащих резервных копий потеря данных неизбежна.
Надежность системы
Резервные копии данных помогают сделать приложения более устойчивыми в случае неожиданных сбоев и ошибок. Члены команды могут случайно удалить тома во время обычной работы. Наличие резервных копий позволяет восстановить приложения до самого последнего состояния, сокращая время простоя и потерю данных.
Защита и соблюдение стандартов
Наличие резервных копий помогает повысить общую безопасность приложений и обеспечивает соответствие отраслевым стандартам, защищая от неожиданных сбоев данных и злонамеренных атак. Это особенно важно в регулируемых отраслях, где стандарты целостности данных очень высоки.
Изменения инфраструктуры
Резервы данных упрощают навигацию по изменениям инфраструктуры. При переносе сетей блокчейна к другим поставщикам облачных услуг могут потребоваться различные механизмы хранения для снижения затрат. Наличие полных резервных копий делает такие переходы плавными и безопасными.
Сетевая реализация
В этом руководстве предполагается, что уже есть настроенная сеть блокчейна на платформе для контейнеров с отдельными пространствами имен для каждой организации, где работают все ее сервисы.
Настройка сети должна иметь пространство имен для каждой организации, а внутри каждого пространства имен должны быть определенные типы развертываний.
Каждое организационное пространство имен обычно имеет:
- •Некоторые узлы-аналоги
- •Базы данных Ledger
- •Серверы центров сертификации для организаций, которым нужно регистрировать новые идентификаторы
- •Базы данных серверов центров сертификации
- •Услуга заказа для организаций, которые участвуют в этой услуге
Сохранение данных в контейнерных средах
Приложения с состоянием должны хранить и извлекать данные, чтобы нормально работать. Приложение может само справляться с этой задачей или полностью или частично передать ее другому приложению с состоянием, например базе данных.
В конце концов, всё хранится в виде файлов или папок. Эти приложения обычно настроены на использование определённых путей к файлам, в которых они хранят постоянные данные.
Развертывание контейнеров используется для обеспечения постоянства данных блокчейна с помощью комбинаций:
- •Постоянные объемы монтируются с постоянными томами
- •Карты конфигурации
- •Безопасное хранение объектов
Конфиденциальные данные, такие как криптографические ключи и сертификаты, монтируются как объекты безопасного хранения. Данные конфигурации, такие как файлы спецификаций, монтируются как карты конфигурации.
Это значит, что файлы и папки, которые есть во всех путях монтирования постоянных томов, объектах безопасного хранения и картах конфигурации, составляют полный набор данных для этого развертывания.
Защитите свою инфраструктуру блокчейна уже сегодня
Используйте надежные стратегии резервного копирования, чтобы защитить данные блокчейна и обеспечить непрерывность работы.
Организация данных узлов-аналогов
Узлы-аналоги хранят часть данных локально в стандартных местах, а остальные данные передают в базы данных реестра.
Папка «Безопасность транспортного уровня» содержит сертификат и пару ключей для узла-аналога.
Папка конфигурации fabric содержит файлы спецификаций, в которых есть настройки, использовавшиеся при запуске пира.
Папка поставщика услуг членства содержит информацию о членстве для коллег, сертификат и ключ регистрации, цепочку сертификатов с сервера центра сертификации.
Папка администратора службы членства содержит учетные данные администратора.
Папка «production» содержит части данных главной книги, в том числе:
- •Сама блокчейн
- •Установленный цепочный код и данные о жизненном цикле
- •Хранилища личных данных
- •Временные хранилища, включенные во время отправки транзакции
Организация данных службы заказов
Узлы службы заказов хранят большинство данных локально в стандартных местах. Несколько папок похожи на те, что есть в узлах-аналогах, но они используются для хранения:
- •Информация о членстве в сервисе
- •Сертификат безопасности транспортного уровня и пары ключей
- •Сертификат регистрации и пары ключей
Папка ledger хранит цепочки, в которые входит эта служба упорядочивания, и ожидающие операции.
Папка production содержит файлы, которые относятся к определенному алгоритму консенсуса и моментальным снимкам.
Организация данных сервера сертификационного центра
Серверы центров сертификации хранят часть данных локально в стандартных местах, а остальные — в базах данных серверов центров сертификации.
Папка сертификационного центра Fabric содержит:
- •Серверные сертификаты
- •Сертификаты безопасности транспортного уровня
- •Файлы конфигурации, которые используются при запуске службы
При восстановлении можно сохранить и использовать новые сертификаты безопасности транспортного уровня и файл конфигурации сервера для центра сертификации, так как он отражает последние изменения профиля, но заменить остальное содержимое, такое как сертификаты регистрации, содержимым из предыдущего кластера.
Стратегии сохранения данных
Сначала убедитесь, что вы сохранили объекты безопасного хранения и карты конфигурации. Есть несколько способов сделать резервную копию данных, которые есть в томах.
Один из способов — делать снимки томов, которые используют эти сервисы. Другой способ — использовать специальные сервисы или инструменты, которые были разработаны именно для этого и имеют разные функции и возможности.
Выбери подходящую стратегию сохранения, исходя из своих нужд и контекста. Некоторые подходы могут упростить перенос рабочих нагрузок между кластерами, а некоторые — нет.
Как восстановить данные
Как восстановить данные зависит от того, как вы их сохраняли. Посмотрите документацию по восстановлению для выбранного вами метода.
Сначала воссоздайте объекты безопасного хранения и карты конфигурации из сохраненных данных. Затем переведите службы в спящий режим и скопируйте сохраненные данные в под.
Повторите этот процесс для всех сервисов во всех пространствах имен, позаботившись о восстановлении нормально смонтированных данных.
Сначала запустите независимые службы, такие как базы данных реестра и базы данных сервера центра сертификации, а затем переходите к остальным службам. Такой поэтапный подход помогает обеспечить выполнение зависимостей перед запуском зависимых служб.
Проверка сохранности
Блокчейн-сети — это распределенные системы, поэтому при резервном копировании и восстановлении данных могут возникнуть проблемы с согласованностью.
В любой момент высота блокчейна на узлах-аналогах может меняться по разным причинам, включая:
- •Скорость сети
- •Географическая близость
- •Тип узла-аналога
Лидерские одноранговые узлы первыми получают блоки от службы упорядочивания, поэтому они могут фиксировать блоки первыми. Некоторые одноранговые узлы могут подвергаться внутренним сбоям, от которых они восстанавливаются путем повторения шагов, что естественным образом приводит к фиксации блоков позже, чем у других.
Это можно решить двумя способами. Во-первых, создайте окно без транзакций, где никакие транзакции не отправляются в сеть. Затем запросите состояние реестра в блокчейне с помощью команд интерфейса командной строки, чтобы убедиться, что все узлы-аналоги находятся на одном уровне, прежде чем начинать процесс сохранения.
После восстановления данных повторите проверку, чтобы убедиться, что все сделано правильно. Просмотрите журналы службы соседей и заказов, чтобы убедиться, что все работает как надо.
Этот шаг проверки очень важен, чтобы убедиться, что восстановленная сеть работает точно так же, как и до сохранения.
Заключительные мысли
В этом руководстве мы подробно рассказали, как и где сети блокчейна на платформах оркестрации контейнеров хранят данные, какие плюсы в том, чтобы сохранять данные, и как восстанавливать или переносить сети, а также провели тесты, чтобы убедиться, что всё работает.
Этот процесс требует тщательного планирования и выполнения. Понимание организации данных различных типов узлов имеет важное значение для успешного сохранения и восстановления.
Каждый компонент хранит данные по-своему, и при комплексном подходе к сохранению нужно учитывать все эти различия.
Восстановление — это не просто копирование файлов в их исходные места. Это тщательная последовательность действий, которая начинается с независимых сервисов и переходит к зависимым.
Распределенный характер сетей блокчейна добавляет некоторую сложность и означает, что нужно сделать дополнительные шаги по проверке, чтобы убедиться, что все узлы синхронизированы после восстановления.
Распределенный характер сетей блокчейна означает, что все сложнее, и нам нужны надежные процедуры сохранения и восстановления, чтобы обеспечить непрерывность бизнеса и защитить ценные данные блокчейна в случае:
- •Случайные удаления
- •Перенос инфраструктуры
- •Сценарии восстановления после сбоев
Регулярное тестирование этих процедур не менее важно, чтобы убедиться, что они работают правильно, когда это действительно нужно.
