Harbor w architekturze z replikacją obrazów pomiędzy trzema Data Center

Wstep.

W poprzednim artykule został przedstawiony jeden z możliwych scenariuszy jaki można zastosować Postanowiłem przedstawić drugi wariant możliwości. W jednym z moich projektów wykorzystałem poniższy wariant:

1. Opis architektury
Przedstawiony model obejmuje trzy instancje Harbor zlokalizowane w różnych Data Center (DC1, DC2, DC3), gdzie:

• Harbor 1 w DC1 pełni rolę aktywnego głównego węzła, który obsługuje żądania i zarządza główną kopią obrazów.
• Harbor 2 i Harbor 3 w DC2 oraz DC3 działają jako węzły standby, replikujące obrazy z Harbor 1.
• Mechanizm replikacji obrazów umożliwia synchronizację danych między Data Center w celu zapewnienia dostępności i konsystencji obrazów w przypadku awarii lub potrzeby lokalnego dostępu.

Ruch użytkowników i aplikacji jest kierowany przez VIP HA Proxy, który rozdziela żądania i kieruje je do aktywnej instancji Harbor lub węzłów standby.

2. Kluczowe założenia systemu

• Replikacja obrazów:
  • Obrazy przesyłane między instancjami są synchronizowane automatycznie, co zapewnia konsystencję danych w różnych lokalizacjach.
  • Mechanizm oparty na harmonogramie lub zdarzeniach, np. publikacji nowego obrazu.
• Wysoka dostępność:
  • W przypadku awarii DC1 (Harbor 1 Active), węzły standby (Harbor 2 lub Harbor 3) mogą przejąć ruch przy minimalnym czasie przestoju.
• Globalna obsługa:
  • Dostępność w wielu regionach umożliwia optymalizację wydajności i skrócenie czasu dostępu użytkowników do obrazów.
• Zarządzanie VIP HA Proxy:
  • Decyduje o tym, która instancja jest aktywna i obsługuje ruch w zależności od stanu infrastruktury.

3. Wymagania techniczne

• Replikacja obrazów:
  • Wymaga stabilnych połączeń między Data Center (najlepiej z niskim opóźnieniem i wysoką przepustowością).
  • Mechanizmy autoryzacji i szyfrowania dla zabezpieczenia przesyłanych danych (TLS, klucze API).
• HA Proxy:
  • Zarządzanie adresem VIP (Virtual IP) w celu przekierowania ruchu do aktywnej instancji.
  • Zintegrowany mechanizm monitorowania stanu instancji Harbor.
• Zasoby dla każdej instancji:
  • Baza danych (np. PostgreSQL) do przechowywania metadanych.
  • Redis jako pamięć podręczna dla zwiększenia wydajności.
• Obsługa lokalnych obrazów:
  • Harbor w DC2 i DC3 musi być w stanie przechowywać kopie lokalne dla minimalizacji opóźnień.

4. Korzyści z wdrożenia takiej architektury

• Wysoka dostępność i odporność na awarie:
  • Dzięki replikacji i standby, system zachowuje dostępność nawet przy awarii głównego Data Center.
• Globalny dostęp:
  • Użytkownicy i aplikacje w różnych regionach mogą korzystać z najbliższego węzła, co zwiększa wydajność.
• Optymalizacja transferów danych:
  • Lokalna replikacja obrazów zmniejsza konieczność wielokrotnych transferów między regionami.
• Zabezpieczenie danych:
  • Replikacja służy jako mechanizm ochrony danych, zapewniając ich zachowanie nawet w przypadku awarii jednego z węzłów.
• Elastyczność:
  • Możliwość dodawania kolejnych instancji w innych regionach w miarę rozwoju infrastruktury.

5. Przebieg działania

• Publikacja nowego obrazu w Harbor 1 w DC1 automatycznie uruchamia mechanizm replikacji do Harbor 2 (DC2) i Harbor 3 (DC3).
• W przypadku zapytań użytkowników, HA Proxy kieruje je do aktywnej instancji, zapewniając równoczesny dostęp do lokalnych kopii obrazów.
• Jeśli DC1 (Harbor 1 Active) stanie się niedostępny, HA Proxy automatycznie przełącza ruch na Harbor 2 lub Harbor 3, które mają aktualne repliki obrazów.

6. Zastosowanie w praktyce
Taka architektura znajduje zastosowanie w dużych organizacjach, które potrzebują globalnej dostępności i niezawodności, np.:

• Międzynarodowe firmy technologiczne z zespołami DevOps w wielu lokalizacjach.
• Środowiska chmurowe i hybrydowe, gdzie obrazy są wykorzystywane w wielu regionach.
• Produkcyjne klastry Kubernetes, które korzystają z lokalnych rejestrów obrazów w różnych regionach.

Ten model zapewnia zarówno elastyczność, jak i bezpieczeństwo w zarządzaniu obrazami kontenerowymi, umożliwiając szybkie i bezpieczne wdrożenia w skali globalnej. Można się również pokusić o zaimplementowanie rozwiązania z podpięciem storage na zewnętrz: . np do S3 jak pokazuje poniższy rysunek.

To tyle na temat HARBORa.