Міграція дисків реєстрових інстансів БД з типом ceph-rbd до типів дисків хмарного сховища

На цій сторінці:

1. Основні типи дисків
2. Загальний опис процесу заміни
3. Алгоритм заміни
4. Завершення

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

Ця інструкція описує процес заміни дисків операційного та аналітичного інстансів бази даних реєстру з дисків за замовчуванням у класі зберігання (storage class) ceph-rbd на нативні диски хмарного провайдера, такі як gp3 (AWS) або thin, thin-csi (vSphere).

1. Основні типи дисків

У таблиці наведено підтримувані типи дисків для міграції:

Таблиця 1. Типи дисків
Тип диска	Опис
`gp3`	Нативний диск хмарного провайдера AWS з можливістю гнучкого розширення об’єму та налаштування параметрів продуктивності (IOPS, пропускна здатність).
`thin-csi`	Нативний диск vSphere з підтримкою гнучкого розширення об’єму.
`thin`	Нативний диск vSphere без можливості гнучкого розширення об’єму.

2. Загальний опис процесу заміни

Процес заміни здійснюється шляхом повторного створення ресурсів PostgresCluster для аналітичного (analytical) та операційного (operational) інстансів з оновленими дисками у новому класі зберігання (gp3, thin або thin-csi). Після цього бази даних відновлюються з наявних резервних копій стандартними інструментами PostgreSQL.

3. Алгоритм заміни

Крок 1: Підготовка до міграції

Перевірте логи інстансів: переконайтеся, що у логах pod-ів analytical та operational немає помилок, зокрема пов’язаних із відпрацюванням реплікації до аналітичного інстансу.
Перевірте наявність резервних копій:
- Переконайтеся, що MinIO містить актуальні повні (full) резервні копії, які виконуються автоматично за встановленим розкладом, для обох інстансів — analytical та operational.
- За замовчуванням бекапи створюються раз на добу.

Крок 2: Закриття зовнішнього доступу

Обмежте доступ до реєстру: закрийте зовнішній доступ до реєстру (кабінети, bp-web-service-gateway тощо).

Крок 3: Резервне копіювання перед міграцією

Створіть повний бекап реєстру: виконайте резервне копіювання реєстру за допомогою інструмента Velero. Для цього зайдіть до центрального Jenkins, знайдіть папку свого реєстру і запустіть пайплайн Create-registry-backup.
Дочекайтеся успішного виконання збірки.

Змініть параметри збереження бекапів: у конфігурації PostgresCluster змініть значення параметра repo1-retention-full, яке встановлене за замовчуванням, на '5' або більше.

Приклад конфігурації бекапів

global:
  log-level-file: detail
  repo1-path: /postgres-backup/smt-dev/operational
  repo1-retention-full: '5'  (1)
  repo1-retention-full-type: count
  repo1-s3-uri-style: path
  repo1-storage-port: '443'
  repo1-storage-verify-tls: 'n'
  start-fast: 'y'

Пояснення параметрів:

1	`repo1-retention-full: '5'` — вказує кількість збережених повних (full) бекапів. У цьому випадку система зберігатиме останні 5 резервних копій.

Створіть нові повні бекапи інстансів: використайте стандартні інструменти PostgreSQL для створення нових повних бекапів для analytical та operational інстансів.

Докладна інструкція зі створення одноразового бекапу: Одноразове створення резервної копії.

Крок 4: Підготовка конфігурацій

Збережіть поточні конфігурації:
- Збережіть YAML-файли для ресурсів PostgresCluster (analytical та operational).
- Збережіть паролі користувача postgres із секретів operational-pguser-postgres та analytical-pguser-postgres.

Оновіть конфігурацію для нових дисків. У коді збережених ресурсів змініть такі поля:

Оновлення конфігурації для нових дисків

instances:
  - dataVolumeClaimSpec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 21Gi  (1)
      storageClassName: thin  (2)

Пояснення параметрів:

1	`storage: 21Gi` — об’єм нового диска для інстансу. За потреби можна змінити цей параметр для відповідності новим вимогам до зберігання.
2	`storageClassName: thin` — вказує клас зберігання для нового диска. У цьому прикладі використовується `thin` (vSphere). Інші можливі варіанти, залежно від cloud-провайдера: `thin-csi` (vSphere) або `gp3` (AWS).

Видаліть заяві поля: metadata, finalizers, status.

Обов’язково видаліть анотації, пов’язані з повними бекапами, додані у ресурси на кроці 3.

Крок 5: Перевірка бекапів

Перевірте статус бекапів:

Зачекайте щонайменше 15–20 хвилин після створення бекапів.
Перевірте Grafana-дашборд PostgreSQLDetails і переконайтеся, що останні бекапи створені зі статусом "успішно".

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

Крок 6: Перестворення `operational` інстансу

Створіть новий інстанс:
- Видаліть поточний ресурс operational.
- Створіть новий ресурс з оновленої конфігурації, визначеної на кроці 4.
Підтвердьте відновлення компонентів:
- Переконайтеся, що всі компоненти ресурсу operational відновлено.
- Після відновлення ресурсу відновляться всі його потрібні компоненти, включаючи новий диск у новому класі зберігання (storage-class). Перевірте підключення нового диска у правильному класі зберігання.
- Відновіть пароль користувача. Для цього внесіть збережений на кроці 4 пароль користувача postgres у секрет operational-pguser-postgres, що заново створився.

Крок 7: Відновлення бази даних для `operational`-інстансу

Виконайте відновлення БД: використайте стандартні інструменти PostgreSQL, щоб відновити базу даних зі створеного бекапу.

Докладна інструкція з відновлення: Відновлення на момент часу чи на конкретну резервну копію

Використовуйте метод відновлення на конкретну резервну копію або до обраного моменту часу.

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

Крок 8: Перестворення та відновлення `analytical`-інстансу

Повторіть кроки 6 та 7 для analytical-інстансу.

Крок 9: Перевірка після міграції

Перевірте логи інстансів:

Переконайтеся, що у логах pod-ів analytical та operational немає помилок.
Перевірте, що реплікація до аналітичного інстансу працює коректно.

Крок 10: Оновлення коду компонента `registry-postgres`

Оновіть налаштування компонента registry-postgres у вашому реєстрі.

Внесіть зміни до коду, оновивши тип дисків та розмір:

Для thin (vSphere) — можна жорстко прописати значення (hardcode).
Для thin-csi (vSphere) та gp3 (AWS) — використовуйте values.yaml.

Рекомендується виконати ці зміни шляхом створення нової гілки з подальшим внесенням змін до файлу helmfile.yaml реєстру.

Крок 11: Запуск пайплайнів

Запустіть пайплайни для реєстру:

Запустіть пайплайн MASTER-Build у центральному сервісі Jenkins Платформи.
(Опційно) Після успішного проходження пайплайну MASTER-Build запустіть пайплайн публікації регламенту у реєстровому Jenkins.

Крок 12: Завершення міграції

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

4. Завершення

Після завершення всіх кроків інстанси operational та analytical повинні працювати з новими дисками у відповідних класах зберігання, а всі дані мають бути відновлені з бекапів.