Оголошення про підтримку Changed Block Tracking API (альфа)

Автор: Prasad Ghangal (Veeam Kasten) Carl Braganza (Veeam Kasten) | Перекладач(і): Андрій Головін |

Ми раді оголосити про альфа-підтримку механізму відстеження змінених блоків. Це покращує екосистему зберігання даних Kubernetes, надаючи ефективний спосіб для драйверів зберігання даних CSI ідентифікувати змінені блоки в знімках (snapshot) PersistentVolume. За допомогою драйвера, який може використовувати цю функцію, ви зможете скористатися швидшими та більш ефективними з точки зору використання ресурсів операціями резервного копіювання.

Якщо ви хочете спробувати цю функцію, перейдіть до розділу Початок роботи.

Що таке відстеження змінених блоків?

Відстеження змінених блоків дозволяє системам зберігання даних ідентифікувати та відстежувати зміни на рівні блоків між моментальними знімками, усуваючи необхідність сканування цілих томів під час операцій резервного копіювання. Це вдосконалення є зміною в інтерфейсі Container Storage Interface (CSI), а також у підтримці зберігання даних у самій системі Kubernetes. З увімкненою альфа-функцією ваш кластер може:

  • Ідентифікувати виділені блоки в знімку тому CSI
  • Визначати змінені блоки між двома знімками одного тому
  • Оптимізувати операції резервного копіювання, зосередившись лише на змінених блоках даних

Для користувачів Kubernetes, які керують великими наборами даних, цей API забезпечує значно ефективніші процеси резервного копіювання. Тепер програми резервного копіювання можуть зосередитися лише на змінених блоках, а не обробляти цілі томи.

Примітка:

На даний момент Changed Block Tracking API підтримується тільки для блокових томів, а не для файлових томів. Драйвери CSI, які керують файловими системами зберігання даних, не зможуть реалізувати цю функцію.

Переваги підтримки відстеження змінених блоків у Kubernetes

У міру зростання популярності Kubernetes для управління критичними даними зі збереженням стану (stateful), потреба в ефективних рішеннях для резервного копіювання стає все більш важливою. Традиційні підходи до повного резервного копіювання стикаються з такими проблемами:

  • Довгі вікна резервного копіювання: повне резервне копіювання великих обсягів даних може займати години, що ускладнює його виконання в межах вікон технічного обслуговування.
  • Високе використання ресурсів: операції резервного копіювання споживають значну пропускну здатність мережі та ресурси вводу-виводу, особливо для великих обсягів даних і застосунків, що інтенсивно використовують дані.
  • Збільшення витрат на зберігання: Повторні повні резервні копії зберігають надлишкові дані, що призводить до лінійного зростання вимог до зберігання, навіть якщо між резервними копіями фактично змінюється лише невеликий відсоток даних.

Changed Block Tracking API вирішує ці проблеми, надаючи вбудовану підтримку Kubernetes для інкрементних резервних копій через інтерфейс CSI.

Ключові компоненти

Реалізація складається з трьох основних компонентів:

  1. CSI SnapshotMetadata Service API: API, що пропонується gRPC, який надає знімки томів та дані про змінені блоки.
  2. SnapshotMetadataService API: Kubernetes CustomResourceDefinition (CRD), який повідомляє про доступність служби метаданих драйвера CSI та деталі підключення до клієнтів кластера.
  3. External Snapshot Metadata Sidecar: проміжний компонент, який підключає драйвери CSI до застосунків резервного копіювання через стандартизований інтерфейс gRPC.

Вимоги до впровадження

Обовʼязки постачальника послуг зберігання

Якщо ви є автором інтеграції сховища з Kubernetes і хочете підтримати функцію відстеження змінених блоків, ви повинні виконати певні вимоги:

  1. Впровадити CSI RPC: Постачальники систем зберігання даних повинні впровадити сервіс SnapshotMetadata, як визначено в специфікаціях CSI protobuf. Цей сервіс вимагає впровадження серверного потокового передавання для таких RPC:

    • GetMetadataAllocated: для ідентифікації виділених блоків у знімку
    • GetMetadataDelta: для визначення змінених блоків між двома знімками

  2. Можливості бекенду сховища: переконайтеся, що бекенд сховища має можливість відстежувати та повідомляти про зміни на рівні блоків.

  3. Розгортання зовнішніх компонентів: інтегруйте з sidecar external-snapshot-metadata, щоб відкрити доступ до сервісу метаданих знімків.

  4. Реєстрація власного ресурсу: зареєструйте ресурс SnapshotMetadataService за допомогою CustomResourceDefinition і створіть власний ресурс SnapshotMetadataService, який повідомляє про доступність служби метаданих і надає деталі підключення.

  5. Підтримка обробки помилок: реалізуйте належну обробку помилок для цих RPC відповідно до вимог специфікації CSI.

Відповідальність за рішення щодо резервного копіювання

A backup solution looking to leverage this feature must:

  1. Налаштування автентифікації: Програма резервного копіювання повинна надавати токен Kubernetes ServiceAccount під час використання Kubernetes SnapshotMetadataService API. Необхідно встановити відповідні права доступу, такі як RBAC RoleBindings, щоб авторизувати ServiceAccount програми резервного копіювання для отримання таких токенів.

  2. Впровадити код потокового передавання на стороні клієнта: Розробити клієнти, які впроваджують API потокового передавання gRPC, визначені у файлі schema.proto. Зокрема:

    • Впровадити код клієнта для потокового передавання для методів GetMetadataAllocated та GetMetadataDelta.
    • Ефективно обробляти відповіді сервера для потокового передавання, оскільки метадані надходять частинами.
    • Обробляти формат повідомлення SnapshotMetadataResponse з належним обробленням помилок.

    Репозиторій GitHub external-snapshot-metadata надає зручний пакет підтримки ітератора для спрощення реалізації клієнта.

  3. Обробка великих потоків даних: Розробка клієнтів для ефективної обробки великих потоків метаданих блоків, які можуть бути повернуті для томів із значними змінами.

  4. Оптимізація процесів резервного копіювання: Модифікація робочих процесів резервного копіювання для використання змінених метаданих блоків з метою ідентифікації та передачі лише змінених блоків, щоб зробити резервне копіювання більш ефективним, скоротивши тривалість резервного копіювання та споживання ресурсів.

Початок роботи

Щоб використовувати відстеження змінених блоків у кластері:

  1. Переконайтеся, що драйвер CSI підтримує знімки томів і реалізує можливості метаданих знімків за допомогою необхідного sidecar external-snapshot-metadata.
  2. Переконайтеся, що власний ресурс SnapshotMetadataService зареєстрований за допомогою CRD.
  3. Перевірте наявність власного ресурсу SnapshotMetadataService для драйвера CSI.
  4. Створіть клієнтів, які можуть отримати доступ до API за допомогою відповідної автентифікації (через токени Kubernetes ServiceAccount).

API надає дві основні функції:

  • GetMetadataAllocated: перелічує блоки, виділені в одному знімку.
  • GetMetadataDelta: перелічує блоки, змінені між двома знімками.

Що далі?

Залежно від відгуків та прийняття, розробники Kubernetes сподіваються перевести реалізацію CSI Snapshot Metadata в бета-версію в майбутніх релізах.

Де я можу дізнатися більше?

Для тих, хто зацікавлений у випробуванні цієї нової функції:

Як я можу долучитися?

Цей проєкт, як і всі проєкти Kubernetes, є результатом наполегливої праці багатьох учасників з різних сфер, які працювали разом. Від імені SIG Storage я хотів би висловити величезну подяку учасникам, які допомогли переглянути дизайн та реалізацію проєкту, зокрема, але не виключно, наступним особам:

Дякуємо також усім, хто долучився до проєкту, зокрема тим, хто допоміг рецензувати KEP та CSI spec PR.

Ті, хто зацікавлений у розробці та розвитку CSI або будь-якої частини системи зберігання даних Kubernetes, можуть приєднатися до Kubernetes Storage Special Interest Group (SIG). Ми завжди раді новим учасникам.

SIG також проводить регулярні зустрічі Data Protection Working Group. Нові учасники можуть долучитися до наших дискусій.

Востаннє змінено June 10, 2026 at 8:00 PM PST: [uk] Ukrainian translation (all-in-one) (4e8fe0f729)