Вступ
У світі розподілених систем трапляються катастрофічні помилки. Уявіть, що ви випадково видалили цілу низку кластерів зі своєї інфраструктури блокчейну. Такі випадки можуть мати руйнівні наслідки.
Найкращий спосіб уникнути таких катастроф — це зберігати відповідні резервні копії даних. При роботі з корпоративними блокчейнами у контейнерних оркестраційних фреймворках наявність резервних копій даних є абсолютно критичною, особливо при впровадженні стратегії резервного копіювання блокчейну Kubernetes та надійної стратегії резервного копіювання контейнерної оркестрації.
Поєднання цих технологій забезпечує потужну та надзвичайно безпечну платформу для обробки транзакцій блокчейну. Сама структура є відкритим рішенням, що розміщується під управлінням спільноти та пропонує платформу для всіх реалізацій, пов'язаних з розподіленим реєстром.
Ця структура має великі переваги, такі як висока продуктивність і масштабованість. Вона забезпечує високий рівень довіри між учасниками з відомими ідентичностями та багатими запитами щодо незмінного реєстру.
Цей посібник містить вичерпну інформацію про резервне копіювання та відновлення блокчейну, захист і відновлення даних у блокчейн-мережах, що працюють у контейнерних середовищах без проблем, включаючи сценарії відновлення після збою Hyperledger Fabric.
Розуміння необхідності резервування даних є основою цього процесу.
Чому резерви даних є необхідними
Створення резервів даних є обов'язковим, а не факультативним, з кількох важливих причин.
Надійність системи
Наявність резервних копій даних дозволяє командам працювати з більшою впевненістю. При використанні хмарного сховища для резервного копіювання додатковий рівень безпеки запобігає різним формам втрати даних, спричиненим:
- •Природні катастрофи
- •Людська помилка
- •Зловмисні атаки
Наприклад, якщо під час перезапуску або збою підсистеми відбуваються помилки у правильній конфігурації шляху монтування для програми у специфікації розгортання, без належних резервних копій втрата даних є неминучою.
Надійність системи
Резерви даних допомагають зробити додатки більш надійними у разі несподіваних збоїв та помилок. Члени команди можуть випадково стерти обсяги даних під час звичайної роботи. Наявність резервів дозволяє відновити додатки до найактуальнішого стану, скорочуючи час простою та втрату даних.
Захист та дотримання стандартів
Наявність резервів допомагає поліпшити загальну безпеку додатків і забезпечує відповідність галузевим стандартам, захищаючи від несподіваних випадків пошкодження даних і зловмисних атак. Це особливо важливо в регульованих галузях, де стандарти цілісності даних є високими.
Зміни інфраструктури
Резерви даних полегшують навігацію по модифікаціях інфраструктури. При міграції блокчейн-мереж до різних хмарних провайдерів можуть знадобитися різні механізми зберігання даних для зниження витрат. Наявність комплексних резервних копій робить такі переходи плавними та безризиковими.
Впровадження мережі
Цей посібник передбачає наявність існуючої мережі блокчейну на платформі оркестрування контейнерів із виділеними просторами імен для кожної організації, де працюють усі її служби.
Мережева конфігурація повинна мати простір імен для кожної організації, а в межах кожного простору імен повинні бути певні типи розгортань.
Кожен організаційний простір імен зазвичай має:
- •Деякі вузли однорангової мережі
- •Бази даних Ledger
- •Сервери сертифікаційних органів для організацій, які потребують реєстрації нових ідентичностей
- •Бази даних серверів сертифікаційних органів
- •Замовлення сервісних вузлів для організацій, які сприяють замовленню сервісу
Збереження даних у контейнерних середовищах
Державні додатки повинні зберігати та отримувати дані для належного функціонування. Додаток може самостійно виконувати цю функцію або повністю чи частково делегувати її іншому державному додатку, наприклад базі даних.
Зрештою, все зберігається у вигляді файлів або папок. Ці програми зазвичай налаштовані на використання певних шляхів до файлів, на яких вони зберігають постійні дані.
Розгортання контейнерів використовуються для досягнення стійкості даних блокчейну за допомогою комбінацій:
- •Постійні підключення обсягів з постійними обсягами
- •Карти конфігурації
- •Захищені об'єкти зберігання
Чутлива інформація, така як криптографічні ключі та сертифікати, монтується як об'єкти безпечного зберігання. Дані конфігурації, такі як файли специфікацій, монтуються як карти конфігурації.
Це означає, що файли та папки, які знаходяться у всіх шляхах монтування постійних томів, об'єктах безпечного зберігання та картах конфігурації, складають повний набір даних для цього розгортання.
Захистіть свою інфраструктуру блокчейну вже сьогодні
Впроваджуйте комплексні стратегії резервного копіювання для захисту даних блокчейну та забезпечення безперебійної роботи бізнесу.
Організація даних вузлів-однолітків
Вузли-однорангові зберігають деякі дані локально в стандартних місцях, а решту даних делегують до баз даних реєстру.
Папка безпеки транспортного рівня містить сертифікат і пару ключів для вузла-однорангового вузла.
Папка конфігурації fabric містить файли специфікацій, які містять конфігурацію, що використовувалася під час запуску однорангового вузла.
Папка постачальника послуг членства містить інформацію про членство для однорангових вузлів, сертифікат реєстрації та ключ, ланцюжок сертифікатів із сервера центру сертифікації.
Папка адміністратора служби членства містить облікові дані адміністратора.
Папка виробництва містить частини даних головної книги, які включають:
- •Сам блокчейн
- •Встановлений ланцюговий код та дані про життєвий цикл
- •Приватні сховища даних
- •Тимчасові сховища, включені під час подання транзакції
Організація даних служби замовлення
Вузли служб замовлення зберігають більшість даних локально в стандартних місцях. Декілька папок схожі на ті, що є в однорангових вузлах, але вони використовуються для зберігання:
- •Інформація про членство в службі замовлення
- •Сертифікат безпеки транспортного рівня та пари ключів
- •Сертифікат про реєстрацію та пари ключів
Папка «ledger» зберігає ланцюжки, до яких належить ця служба сортування, та операції, що очікують на виконання.
Папка виробництва містить файли, що стосуються конкретного алгоритму консенсусу та знімків.
Організація даних сервера сертифікаційного центру
Сервери центру сертифікації зберігають деякі дані локально в стандартних місцях, а решту — у базах даних сервера центру сертифікації.
Папка сертифікаційного органу тканини містить:
- •Сертифікати сервера
- •Сертифікати безпеки транспортного рівня
- •Конфігураційні файли, які використовуються під час запуску служби
Під час відновлення ви можете зберегти та використовувати нові сертифікати безпеки транспортного рівня та файл конфігурації сервера для центру сертифікації, оскільки він відображає останні зміни профілю, але замінити решту вмісту, наприклад сертифікати реєстрації, вмістом з попереднього кластера.
Стратегії збереження даних
Спочатку переконайтеся, що ви зберегли об'єкти безпечного зберігання та карти конфігурації. Існує кілька методів резервного копіювання даних, що містяться в томах.
Один із способів — зробити знімки томів, які використовують ці служби. Інший спосіб — використовувати спеціалізовані служби або інструменти, спеціально розроблені для цієї мети, з різними функціями та можливостями.
Виберіть правильну стратегію збереження відповідно до ваших потреб і контексту. Деякі підходи можуть спростити міграцію робочих навантажень між кластерами, а інші — ні.
Процедури відновлення даних
Стратегія відновлення залежить від реалізованої стратегії збереження. Зверніться до відповідної документації з відновлення для обраного вами методу.
Почніть з відтворення об'єктів безпечного зберігання та карт конфігурації з збережених даних. Далі переведіть служби в режим очікування та скопіюйте збережені дані в під.
Повторіть цей процес для всіх служб у всіх просторах імен, подбавши про відновлення нормально змонтованих даних.
Спочатку запустіть незалежні служби, такі як бази даних реєстрів та бази даних серверів сертифікаційних органів, а потім перейдіть до решти служб. Такий поетапний підхід допомагає забезпечити виконання залежностей перед запуском залежних служб.
Перевірка узгодженості збереження
Мережі блокчейнів є розподіленими системами, тому процеси резервного копіювання та відновлення становлять виклики для узгодженості даних.
У будь-який момент висота блокчейну на однорангових вузлах може змінюватися з різних причин, включаючи:
- •Швидкість мережі
- •Географічна близькість
- •Тип вузла-однорангового вузла
Лідерські однорангові вузли першими отримують блоки від служби упорядкування, тому вони можуть першими підтверджувати блоки. Деякі однорангові вузли можуть зазнавати внутрішніх збоїв, від яких вони відновлюються шляхом повторення кроків, що має природний наслідок у вигляді підтвердження блоків пізніше за інших.
Це можна пом'якшити двома способами. По-перше, створіть вікно без транзакцій, де транзакції не надсилаються до мережі. Потім, перед початком процесу збереження, запитайте стан реєстру в блокчейні за допомогою команд інтерфейсу командного рядка, щоб переконатися, що всі вузли-однорангові знаходяться на однаковій висоті.
Після відновлення даних повторіть процес перевірки, щоб переконатися, що відновлення було виконано правильно. Перегляньте журнали сервісів однорангового зв'язку та замовлення, щоб переконатися, що все працює належним чином.
Цей крок перевірки є критично важливим для забезпечення того, щоб відновлена мережа функціонувала ідентично до оригінальної мережі до моменту збереження.
Останні думки
У цьому посібнику детально розглянуто, як і де мережі блокчейнів на платформах оркестрування контейнерів зберігають дані, переваги збереження даних та способи відновлення або міграції мереж, а також тести перевірки для забезпечення успіху.
Цей процес вимагає ретельного планування та виконання. Розуміння організації даних різних типів вузлів є необхідною умовою для успішного збереження та відновлення.
Кожен компонент зберігає дані по-різному, і цілісний підхід до збереження повинен враховувати всі ці відмінності.
Відновлення — це не просто копіювання файлів у їхні початкові місця розташування. Воно передбачає ретельне послідовне виконання операцій, яке починається з незалежних служб і переходить до залежних.
Розподілений характер мереж блокчейну додає певної складності та означає, що необхідно вжити додаткових заходів перевірки, щоб гарантувати синхронізацію всіх вузлів після відновлення.
Розподілений характер мереж Blockchain означає більшу складність, і нам потрібно мати надійні процедури збереження та відновлення, щоб забезпечити безперебійність бізнесу та захистити цінні дані Blockchain у разі:
- •Випадкові видалення
- •Міграція інфраструктури
- •Сценарії відновлення після аварій
Регулярне тестування цих процедур є не менш важливим, щоб переконатися, що вони працюють правильно, коли це дійсно потрібно.
