Керування розкладом резервного копіювання реєстру

🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.

1. Загальний опис

Платформа дозволяє налаштувати розклад створення резервних копій для компонентів реєстру та визначити тривалість їх зберігання у сховищі.

Платформа використовує інструмент Velero для резервного копіювання Kubernetes-ресурсів, таких як PVC, розгортання (deployments), конфігурації та секрети. Velero зберігає резервні копії в окремому сховищі MinIO, яке розгорнуте поза межами OpenShift-кластера, щоб ізолювати критичні дані від потенційних збоїв або інцидентів усередині кластера.

Дані з об’єктних бакетів Ceph OBC не входять до зони дії Velero. Щоб зберігати ці дані, Платформа підтримує окремий механізм реплікації. Реплікація автоматично копіює вміст OBC-бакетів до визначеного сховища. За замовчуванням дані реплікуються до MinIO, але адміністратор може вказати інше S3-сумісне сховище, наприклад Amazon S3 або Google Cloud Storage.

backup schedule registry components 001
Зображення 1. Схема процесів резервного копіювання та реплікації на Платформі

Ви можете налаштувати розклад резервного копіювання та реплікації у форматі cron через інтерфейс Control Plane.

Тривалість зберігання резервних копій визначається у днях. Значення має бути цілим числом, не меншим за 1.

Резервне копіювання та реплікація мають окремі розклади. Див. деталі у розділах нижче.

Платформа зберігає налаштовані розклади у файл deploy-templates/values.yaml. Це відбувається під час виконання пайплайну MASTER-Build, який оновлює конфігурацію реєстру.

Jenkins-пайплайн Create-registry-backup відповідає за запуск процесів резервного копіювання відповідно до розкладів, які ви налаштовуєте в Control Plane.

Пайплайн запускає два незалежні процеси: створення резервної копії за допомогою Velero та реплікацію даних із Ceph OBC. Кожен процес має власний розклад, але виконується в рамках одного пайплайну.

Velero створює резервні копії ресурсів Kubernetes і зберігає їх у MinIO. Реплікація Ceph OBC копіює дані до вказаного S3-сумісного сховища. Платформа дозволяє окремо керувати часом запуску обох процесів.

2. Налаштування розкладу резервного копіювання

Плануйте створення резервних копій на періоди з найменшим навантаженням на систему. Найкраще запускати бекапи вночі — це допоможе уникнути збоїв і не вплине на роботу користувачів.

2.1. Налаштування розкладу створення резервних копій реєстру та періоду їх зберігання

Виконайте наступні дії, щоб налаштувати розклад:

  1. Увійдіть до вебінтерфейсу Control Plane як адміністратор реєстру.

  2. Перейдіть до розділу Реєстри та оберіть потрібний реєстр.

    change key 01

  3. Натисніть кнопку Редагувати у правому верхньому куті.

    Налаштування розкладу резервного копіювання та часу зберігання резервних копій доступне також при створенні реєстру, але не є обовʼязковим кроком.

    change key 02

  4. Відкрийте секцію Резервне копіювання. Тут можна встановити розклад створення резервних копій та період зберігання. Активуйте перемикач та налаштуйте розклад створення автоматичних резервних копій.

    За замовчуванням налаштування автоматичних резервних копій вимкнено для нових реєстрів.

    backup schedule registry components 01

    Розклад резервного копіювання налаштовується у форматі unix-cron та визначається за київським часом.

    За замовчуванням часовий пояс Europe/Kiev встановлюється у конфігурації values.yaml та на рівні поду з Jenkins як змінна середовища.

    Враховується зміщення на +2 години (UTC+2) у зимовий та +3 години (UTC+3) у літній час.

    Скористайтеся ресурсом https://crontab.guru/ — простим та зручним редактором для виразів cron, щоб краще зрозуміти логіку налаштувань розкладу.

    • У полі Розклад вкажіть, наприклад, таке значення: 5 10 * * MON-FRI. Використовуйте пробіл як роздільник.

      Таке налаштування означає, що резервна копія для середовища реєстру буде створюватися кожного дня, з понеділка по п’ятницю, о 10:05 за київським часом.

      Після введення розкладу резервного копіювання, на інтерфейсі з’являється підказка, яка показує час 3-х наступних запусків створення резервних копій:

      Наступні запуски резервного копіювання (за київським часом):

      • 09.06.2023 10:05:00

      • 10.06.2023 10:05:00

      • 11.06.2023 10:05:00

    • У полі Час зберігання (днів) вкажіть, наприклад, 5. Тобто бекап зберігатиметься у сховищі протягом 5 днів.

      Значення періоду зберігання має бути цілим числом не меншим за 1. Щоб уникнути втрати даних, переконайтеся, що період зберігання довший за інтервал між створенням резервних копій.

      backup schedule registry components 02

  5. Перейдіть до налаштування реплікації даних об’єктних бакетів Ceph, або залиште значення за замовчуванням та натисніть Підтвердити внизу сторінки.

2.2. Реплікація даних об’єктних бакетів Ceph

2.2.1. Як працює механізм реплікації

Платформа використовує два типи сховищ:

  • MinIO — для зберігання резервних копій, створених компонентом Velero.

  • Ceph OBC (Object Bucket Claims) — для зберігання робочих даних реєстрів, таких як історія виконання бізнес-процесів, тимчасові файли тощо.

Velero — це інструмент, що забезпечує резервне копіювання, відновлення, міграцію та аварійне відновлення компонентів Платформи. Зокрема, він дозволяє створювати резервні копії стану OpenShift-середовища (наприклад, конфігурацій, розгортань, секретів, PVC) і зберігати їх в S3-сумісному сховищі, такому як MinIO або Amazon S3.

Важливо розуміти, що Velero не охоплює Ceph OBC-бакети, тому для захисту цих даних від втрати та їх збереження в окремому сховищі застосовується механізм реплікації об’єктних бакетів.

Реплікація Ceph OBC полягає в автоматичному копіюванні вмісту об’єктних бакетів реєстру до іншого S3-сумісного сховища, відповідно до налаштувань, визначених адміністратором у Control Plane.

Залежно від конфігурації доступні два сценарії:

  • За замовчуванням: дані з Ceph OBC автоматично реплікуються до платформного MinIO-бакета, де також зберігаються резервні копії Velero.

  • За наявності кастомних налаштувань (реплікація налаштована через Control Plane): дані з Ceph OBC реплікуються до будь-якого іншого S3-сумісного сховища, яке вказане адміністратором (наприклад, Amazon S3, Google Cloud Storage тощо). У цьому випадку адміністратор налаштовує адресу з’єднання (endpoint), облікові дані доступу та розклад запуску реплікації.

Таким чином, ця функціональність забезпечує гнучкість і варіативність зберігання, дозволяючи адаптувати резервне копіювання OBC-даних до вимог конкретного середовища або політик безперервності.

2.2.2. Як працює процес резервного копіювання та реплікації

Налаштування резервного копіювання та реплікації в інтерфейсі Control Plane відбувається так:

  1. Адміністратор реєстру активує резервне копіювання та вказує розклад (cron-вираз).

  2. Створюється Jenkins-пайплайн Create-Registry-Backup, який згідно з розкладом виконує два паралельні процеси:

    • Створення резервної копії реєстру за допомогою Velero (включаючи всі PVC та Kubernetes-ресурси у форматі YAML), що зберігається у MinIO-бакеті.

    • Реплікація Ceph OBC-бакетів до визначеного сховища. За замовчуванням — до MinIO-бакета, або до кастомного — якщо налаштовано.

  3. Якщо змінити місце зберігання реплікацій, то це вплине лише на цільове сховище для Ceph OBC, але не змінить сховище для Velero — останнє завжди залишається у MinIO.

Таким чином, Платформа забезпечує двокомпонентну модель резервного копіювання:

  • Резервне копіювання ресурсів Kubernetes через Velero.

  • Окрема реплікація Ceph OBC-даних до резервного сховища.

2.2.3. Налаштування розкладу реплікації

  1. Увійдіть до вебінтерфейсу Control Plane як адміністратор реєстру.

  2. Перейдіть до розділу Реєстри та оберіть потрібний реєстр.

    change key 01

  3. Натисніть кнопку Редагувати у правому верхньому куті.

    change key 02

  4. Відкрийте секцію Резервне копіювання  Резервне копіювання реплікацій об’єктів S3 та налаштуйте розклад реплікації.

    backup schedule registry components 10

    Розклад резервного копіювання налаштовується у форматі unix-cron та визначається за UTC.

    Часова зона встановлюється у конфігурації values.yaml та на рівні поду з Jenkins як змінна середовища.

    Скористайтеся ресурсом https://crontab.guru/ — простим та зручним редактором для виразів cron, щоб краще зрозуміти логіку налаштувань розкладу.

    У полі Розклад вкажіть, наприклад, таке значення: 25 12 * * *. Використовуйте пробіл як роздільник. Таке налаштування означає, що дані з Ceph OBC реплікуватимуться щодня о 12:25.

    Якщо не вказати власний розклад, то система використає значення за замовчуванням згідно з UTC: 30 17 * * * *.

    Після введення розкладу резервного копіювання, на інтерфейсі з’являється підказка, яка показує час 3-х наступних запусків створення резервних копій:

    Наступний запуск резервного копіювання реплікацій об’єктів S3 (за UTC):

    • 09.06.2023 12:25:00

    • 10.06.2023 12:25:00

    • 11.06.2023 12:25:00

  5. Налаштуйте місце зберігання реплікацій.

    Якщо не встановити власних значень для зберігання, система використає власні значення за замовчуванням, встановлені під час розгортання реєстру.

    1. Встановіть власні значення для зберігання реплікацій. Для цього натисніть Задати власні значення та у новому вікні заповніть відповідні поля:

      Таблиця 1. Приклад налаштування зберігання реплікацій для Amazon S3
      Поле Опис

      Ім’я бакета

      Ім’я має бути унікальним серед усіх бакетів у вашому S3-середовищі.

      Довжина — від 3 до 63 символів.

      Допустимі символи: "a-z", "0-9", ".", "-".

      Приклад: my-s3-bucket-123.

      Endpoint

      URL, за яким сервіс підключається до S3-сховища.

      Приклад: https://endpoint.com.

      Для Amazon S3:

      Логін

      Облікові дані, надані постачальником S3-сервісу.

      Для Amazon S3 — AWS Access Key ID

      Приклад: AKIAIOSFODNN7EXAMPLE.

      Пароль

      Облікові дані, надані постачальником S3-сервісу.

      Для Amazon S3 — AWS Secret Access Key

      Приклад: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY.

    2. Натисніть Підтвердити, щоб зберегти власні значення для зберігання, або Відмінити, щоб скасувати внесення змін.

      backup schedule registry components 9

  6. На сторінці Резервне копіювання знову натисніть Підтвердити, щоб зберегти зміни та сформувати запит на оновлення конфігурації реєстру (див. нижче).

    backup schedule registry components 11

2.3. Застосування конфігурації розкладу

У результаті виконання налаштувань розкладу резервного копіювання, описаних у попередніх підрозділах, формується запит на оновлення зі статусом Новий та типом Редагування реєстру.

  1. У розділі Реєстри  Запити на оновлення знайдіть необхідний запит.

    cp submit mr 1

  2. Відкрийте сформований запит, натиснувши іконку перегляду 👁.

  3. У новому вікні зіставте 2 версії змін, переконайтеся, що внесені вами дані вірні, та натисніть Підтвердити. Ви також можете відразу відхилити зміни до конфігурації, натиснувши Відхилити.

    Запропоновані зміни вносяться до конфігурації файлу deploy-templates/values.yaml репозиторію реєстру у разі підтвердження.

    backup schedule registry components 12

    cp submit mr 3

    У результаті запит набуває статусу Підтверджено.

  4. Зачекайте, доки виконається збірка коду. Це може зайняти кілька хвилин.

Після успішного застосування конфігурації, у встановлений час запуститься Jenkins-пайплайн Create-registry-backup. Він застосує параметри заданої конфігурації й створить резервні копії та реплікації у відповідних сховищах.

3. Створення та перевірка бекапів

У визначену дату та час система створює резервні копії, згідно із розкладом у конфігурації.

Перевірити стан створення резервної копії реєстру можна так:

  1. Відкрийте Control Plane  Реєстри  Швидкі посилання, знайдіть розділ Адміністративна зона реєстру та перейдіть до Сервісу розгортання регламенту (Jenkins).

    quick links 3

  2. Перейдіть до теки з необхідним реєстром та оберіть пайплайн Create-registry-backup-<registry-name>, де <registry-name> — назва вашого реєстру. Якщо пайплайн підсвічується зеленим, то збірка є успішною.

    backup schedule registry components 2

  3. Відкрийте деталі збірки.

    backup schedule registry components 3

  4. Відкрийте Console Output, щоб переглянути технічний лог виконання пайплайну.

    backup schedule registry components 4

  5. Прокрутіть бігунок униз сторінки та переконайтеся, що резервну копію реєстру створено. Ви маєте побачити наступний вираз:

    Console Output. Успішне створення резервної копії реєстру
    [INFO] Velero backup - external-1-2023-02-17-17-07-36 done with Completed status

    Вираз показує, що створено резервну копію для реєстру із певною назвою (тут — external-1), датою та часом створення і статусом успішного завершення.

    backup schedule registry components 5

Після закінчення строку зберігання, система видаляє застарілі резервні копії.

4. Пов’язані сторінки