Розуміння нашої стратегії міграції

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

Наша стратегія міграції дозволяє безперебійно переходити з одного оточення в інше без прив’язки до конкретної хмари або середовища. Наш пріоритет — забезпечення безпеки даних, консистентності та доступності під час міграції. Ми гарантуємо цілісність даних та мінімальні перебої в роботі шляхом контролю та обмеження процесу міграції в межах наших визначених кластерів.

1. Cloud-агностичний підхід

Наша система не залежить від конкретного оточення. Вона є cloud-agnostic, тобто не прив’язана до середовища. Це означає, що ви можете мігрувати реєстри, їх компоненти та ресурси між різними оточеннями, від публічних до приватних хмар, на локальні системи (наприклад, з AWS на vSphere), та навпаки.

2. Сценарії для двох кластерів

Припустимо, у нас є кластер OKD A на AWS і кластер OKD В на vSphere. Міграція можлива між цими двома кластерами.

3. Попередні умови для міграції

Встановлення Платформи та її основних компонентів інфраструктури на кластерах A та B необхідне для початку міграції. Головне, що треба пам’ятати — міграція можлива лише між однаковими версіями (скажімо, версія 1.9.5) Платформи та реєстрів на обох кластерах A і B.

4. Обмеження зовнішньої міграції

  • Міграція до чистого кластера OKD у будь-якому оточенні неможлива. Це обмеження існує, тому що критичні процеси, як вхід до порталів або інструментів адміністрування, залежать від Keycloak. Keycloak є частиною управління користувачами й встановлюється та оновлюється під час розгортання Платформи.

  • Базова версія регламенту реєстру береться із центрального Gerrit-репозиторію під час розгортання Платформи.

  • Образи Docker, які є життєво важливими для роботи, отримуються з Docker Registry Nexus під час розгортання Платформи.

5. Процес міграції

Механізм Velero відповідає за процес міграції. Velero — це відкрите програмне забезпечення, адаптоване до потреб нашого продукту. Цей інструмент встановлюється та оновлюється під час розгортання Платформи.

6. Міграція наявних систем на нашу Платформу

Наша Платформа перш за все зосереджена на управлінні етапом "Завантаження" у процесі ETL, який передбачає імпорт попередньо оброблених та трансформованих даних. Перед передачею даних до нашої системи важливо витягти їх з вашої поточної конфігурації та, за потреби, перетворити їх у відповідний формат. Після завершення цих етапів наша Платформа може ефективно та надійно здійснювати процес імпорту даних.

6.1. Короткий огляд процесу ETL

ETL — це скорочення від Витягування, Трансформація, Завантаження. Це основні етапи переміщення даних з однієї системи чи формату в інший:

  1. Витягування: На цьому етапі дані отримуються з різних джерел.

  2. Трансформація: Витягнуті дані перетворюються або обробляються у потрібний формат чи структуру для подальшого використання або зберігання.

  3. Завантаження: На цьому етапі трансформовані дані завантажуються в систему призначення або базу даних.

6.2. Зони відповідальності

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

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

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