CloudCasa by Catalogic dodała Dell PowerStore do macierzy pamięci masowej, które CloudCasa Disaster Recovery może obsługiwać w celu awaryjnego przełączania Kubernetes, obok HPE Alletra i SUSE Storage. Ta sama aktualizacja funkcji dodaje serwer MCP (Model Context Protocol) tylko do odczytu, który pozwala asystentom AI sprawdzać stan kopii zapasowych i odzyskiwania po awarii, a także podgląd funkcji Changed Block Tracking (CBT) dla kopii zapasowych maszyn wirtualnych KubeVirt, która kopiuje tylko bloki zmienione od ostatniego uruchomienia.
Zintegrowane z pamięcią masową odzyskiwanie danych po awarii rozszerza się na Dell PowerStore
PowerStore dołącza do HPE Alletra Storage MP B10000 , HPE Alletra 9000 i SUSE Storage jako dostawcy replikacji dla CloudCasa DR. Podział zadań jest taki sam na każdej platformie: macierz replikuje dane woluminów trwałych do lokalizacji odzyskiwania, synchronicznie lub asynchronicznie w przypadku PowerStore, a CloudCasa obsługuje aspekt Kubernetes w zakresie przełączania awaryjnego i powrotu po awarii dla aplikacji konteneryzowanych i maszyn wirtualnych KubeVirt. Dane woluminów są przenoszone z macierzy do macierzy i nigdy nie przechodzą przez CloudCasa.
CloudCasa rejestruje konfigurację każdego chronionego obciążenia w zreplikowanym woluminie inwentaryzacyjnym i komunikuje się z macierzą poprzez interfejs API REST PowerStore. W przypadku przełączenia awaryjnego najpierw uruchamia ten wolumin inwentaryzacyjny, uruchamia agenta odzyskiwania w klastrze docelowym, a następnie przełącza pozostałe grupy woluminów PowerStore w tryb failover i odbudowuje wdrożenia, zestawy StatefulSets, żądania woluminów trwałych oraz maszyny wirtualne KubeVirt na zreplikowanych woluminach. Ponieważ PowerStore przełącza awaryjnie całe grupy woluminów, CloudCasa zaleca umieszczenie obciążeń o różnych wymaganiach odzyskiwania w oddzielnych grupach.
Funkcja failback oczekuje na potwierdzenie operatora, po czym CloudCasa odwraca replikację w odpowiednich grupach woluminów, tak aby PowerStore resynchronizował tylko zmiany wprowadzone od momentu przełączenia awaryjnego, zmniejszał obciążenia nadal działające w lokalizacji odzyskiwania po awarii, a następnie przekierowywał grupy woluminów z powrotem do macierzy głównej i tam odbudowywał obciążenia. CloudCasa twierdzi, że podejście to dąży do czasu odzyskiwania mierzonego w minutach i bliskiego zeru RPO, gdy PowerStore replikuje synchronicznie. Wyniki zależą od trybu replikacji, rozmiaru obciążenia i odległości między lokalizacjami.
Integracja obejmuje blokowe (SCSI) woluminy trwałe udostępniane za pośrednictwem sterownika PowerStore CSI; odzyskiwanie danych po awarii woluminów NFS i SMB znajduje się w planach CloudCasa. Obsługiwane platformy to Red Hat OpenShift i OpenShift Virtualization, SUSE Rancher/RKE2 i SUSE Virtualization, VMware vSphere Kubernetes Service oraz upstream Kubernetes 1.20 i nowsze. Licencja na odzyskiwanie danych po awarii w CloudCasa jest udzielana na węzeł roboczy w ramach rocznej subskrypcji, niezależnie od produktu do tworzenia kopii zapasowych CloudCasa, zarówno w wersji SaaS, jak i w wersji hostowanej samodzielnie.
Serwer protokołu kontekstu modelu do integracji agentów AI
Serwer MCP pozwala każdemu asystentowi AI obsługującemu zdalne serwery MCP przez HTTP na wysyłanie zapytań do CloudCasa w prostym języku, na przykład dotyczących tego, które zadania tworzenia kopii zapasowych zakończyły się niepowodzeniem w ciągu ostatnich 24 godzin lub które punkty odzyskiwania istnieją dla danej przestrzeni nazw. Serwer wywołuje interfejsy API CloudCasa w imieniu użytkownika, uwierzytelnia się za pomocą klucza API CloudCasa przekazanego w nagłówku HTTP i może wykonywać tylko czynności dozwolone przez rolę tego klucza. Na razie jest on dostępny tylko do odczytu: asystenci mogą wyświetlać listę klastrów, zasad tworzenia kopii zapasowych, zadań, punktów odzyskiwania, przywracania, alertów i celów tworzenia kopii zapasowych, ale nie mogą niczego uruchamiać, tworzyć, edytować ani usuwać.
„Zespoły platformowe wykonują więcej codziennych zadań, korzystając z asystentów AI, i chcą mieć dostęp do statusu kopii zapasowej, obok pozostałych narzędzi” – powiedział Ryan Kaw, globalny wiceprezes ds. sprzedaży i sojuszy w CloudCasa. „Serwer MCP umożliwia to już dziś”.
Podgląd i dostępność śledzenia zmienionych bloków
Wersja zapoznawcza CBT bazuje na obsłudze przyrostowych kopii zapasowych dodanej przez KubeVirt w wersji 1.8, która wykorzystuje możliwości tworzenia kopii zapasowych QEMU i libvirt i działa niezależnie od pamięci masowej. CBT rejestruje, które bloki dysku uległy zmianie od czasu poprzedniej kopii zapasowej, więc CloudCasa kopiuje tylko te bloki, co, jak twierdzi firma, skraca czas tworzenia kopii zapasowych maszyn wirtualnych. W systemie Red Hat OpenShift ta wersja KubeVirt jest dostępna w OpenShift 4.22, a funkcja ta musi zostać włączona jawnie.
Integracja PowerStore DR i serwer MCP są już dostępne, a kopie zapasowe CBT pozostają w wersji zapoznawczej. Aktualizacja dodaje również dedykowaną stronę maszyn wirtualnych, która zawiera listę maszyn wirtualnych we wszystkich zarejestrowanych klastrach wraz z ich stanem uruchomienia i statusem agenta gościa. Administratorzy mogą tam definiować kopie zapasowe i przywracać dane dla każdej maszyny wirtualnej.
Amazon