Autor:Ben Slater , dyrektor ds. produktów, Instaclustr.
Przenoszenie działającego wdrożenia Apache Cassandra do nowej lokalizacji? To naturalne, że masz pewne obawy, na przykład w jaki sposób możesz utrzymać klastry Cassandra w 100% dostępne przez cały proces. Ale faktem jest, że jeśli Twoja aplikacja może pozostać w trybie online podczas zmiany ustawień połączenia, może pozostać w pełni dostępna podczas tego przejścia. Aby zapewnić dodatkową ochronę i spokój ducha, poniższa technika obejmuje również strategię szybkiego przywracania, aby powrócić do pierwotnej konfiguracji, aż do momentu zakończenia migracji.
Oto zalecana siedmioetapowa kolejność operacji migracji klastra Cassandra, która pozwoli uniknąć przestojów:
1. Przygotuj swoje istniejące środowisko.
Przede wszystkim upewnij się, że Twoja aplikacja korzysta z zasad równoważenia obciążenia uwzględniających centrum danych, a także LOCAL_*. Sprawdź też, czy wszystkie obszarów kluczy, które zostaną skopiowane do nowego klastra, są ustawione tak, aby używały strategii NetworkTopologyStrategy jako strategii replikacji. Zaleca się również, aby wszystkie obszary kluczy używały tej strategii replikacji podczas tworzenia, ponieważ późniejsza zmiana może być skomplikowana.
2. Utwórz nowy klaster.
Teraz nadszedł czas, aby utworzyć nowy klaster, do którego będziesz migrować. Kilka rzeczy, na które należy uważać:Upewnij się, że nowy klaster i oryginalny klaster używają tej samej wersji Cassandra i nazwy klastra. Ponadto nowa nazwa centrum danych, której używasz, musi różnić się od nazwy istniejącego centrum danych.
3. Dołącz do klastrów razem.
Aby to zrobić, najpierw wprowadź niezbędne zmiany reguł zapory, aby umożliwić dołączenie klastrów, pamiętając, że mogą być również konieczne pewne zmiany w klastrze źródłowym. Następnie zmień węzły inicjujące nowego klastra i uruchom je. Po wykonaniu tej czynności nowy klaster będzie drugim centrum danych w pierwotnym klastrze.
4. Zmień ustawienia replikacji.
Następnie w istniejącym klastrze zaktualizuj ustawienia replikacji dla obszarów kluczy, które zostaną skopiowane, tak aby dane były teraz replikowane z nowym centrum danych jako miejscem docelowym.
5. Skopiuj dane do nowego klastra.
Po połączeniu klastrów Cassandra rozpocznie replikację zapisów do nowego klastra. Nadal jednak konieczne jest skopiowanie wszelkich istniejących danych za pomocą funkcji przebudowy narzędzia nodetool. Najlepszą praktyką jest wykonywanie tej funkcji w nowym klastrze w jednym lub dwóch węzłach naraz, aby nie nakładać przytłaczającego obciążenia strumieniowego na istniejący klaster.
6. Zmień punkty połączenia aplikacji.
Po zakończeniu wszystkich zastosowań funkcji odbudowy, każdy z klastrów będzie zawierał pełną kopię migrowanych danych, które Cassandra będzie automatycznie synchronizować. Nadszedł czas, aby zmienić początkowe punkty połączenia aplikacji na węzły w nowym klastrze. Po zakończeniu wszystkie odczyty i zapisy będą obsługiwane przez nowy klaster, a następnie zostaną zreplikowane w oryginalnym klastrze. Wreszcie, mądrze jest uruchomić funkcję naprawy w całym klastrze, aby upewnić się, że wszystkie dane zostały pomyślnie zreplikowane z oryginału.
7. Wyłącz oryginalny klaster.
Zakończ proces, wykonując niewielkie porządki po migracji, usuwając oryginalny klaster. Najpierw zmień reguły zapory, aby odłączyć oryginalny klaster od nowego. Następnie zaktualizuj ustawienia replikacji w nowym klastrze, aby zaprzestać replikacji danych do pierwotnego klastra. Na koniec zamknij oryginalny klaster.
I masz to:Twoje wdrożenie Apache Cassandra zostało w pełni zmigrowane, bez przestojów, z niskim ryzykiem oraz w sposób całkowicie bezproblemowy i przejrzysty z punktu widzenia użytkowników końcowych.
O autorze
Ben Slater jest dyrektorem ds. produktów w firmie Instaclustr, dostawcy hostowanej i w pełni zarządzanej infrastruktury danych typu open source Apache Cassandra w chmurze klasy korporacyjnej.
