Migrowanie obciążenia w chmurze do innego regionu
Krok migracji relokacji polega na przeniesieniu obciążenia do nowego regionu. W zależności od obciążenia może istnieć kilka wymagań technicznych, które należy przygotować, ale strategia relokacji obciążenia powinna być jasna. Powinno być gotowe do wykonania relokacji.
Przygotowywanie
Przed rozpoczęciem relokacji obciążenia należy przygotować region docelowy. W razie potrzeby wykonaj następujące kroki, aby przygotować środowisko obciążenia przed przeniesieniem. Dzięki temu masz podstawową sieć regionalną, taką jak centrum regionalne i, w razie potrzeby, łączność między lokalizacjami.
Ustanów strefę docelową. Podczas planowania przenoszenia należy ocenić, czy rozszerza zakres strefy docelowej platformy Azure. Jeśli rozszerzenie jest konieczne, zapoznaj się ze wskazówkami dotyczącymi strefy docelowej platformy Azure jako podstawowym krokiem. Ten krok zapewnia, że twoje podejście jest zgodne z ustalonymi najlepszymi rozwiązaniami. Aby uzyskać więcej informacji, zobacz Dodawanie nowego regionu do istniejącej strefy docelowej platformy Azure. Ważne zagadnienia dotyczące konfigurowania nowej strefy docelowej obejmują:
- Sieć: oceń strukturę sieci, ścieżki routingu i wymagania dotyczące łączności dla strefy docelowej w nowym regionie.
- Integracja: ustal, czy istnieje potrzeba zintegrowania nowej strefy docelowej z nową strefą docelową w regionie źródłowym.
- Selektywna relokacja zasobów: zdecyduj, czy wszystkie zasoby przeniosą się do nowego regionu. Jeśli niektóre zasoby pozostaną w oryginalnej lokalizacji, zaplanuj zrównoważoną topologię sieci między regionami, aby efektywnie zarządzać tymi zasobami rozproszonymi.
Utwórz nowe subskrypcje tylko w razie potrzeby. Utwórz nowe subskrypcje tylko wtedy, gdy musisz zrestrukturyzować zaangażowane usługi i zasoby. Spróbuj zachować obciążenie w istniejącej subskrypcji, jeśli to możliwe, ponieważ utworzenie nowej subskrypcji zwiększa złożoność. Subskrypcje służą jako granice dla budżetów, zasad i kontroli dostępu opartej na rolach (RBACs). W przypadku każdej nowej subskrypcji należy zweryfikować budżety, zasady i RBACs. Jeśli nie przeniesiesz wszystkich zasobów w subskrypcji, musisz ponownie opracować zakres zasad tożsamości i zabezpieczeń, aby dopasować je do mniejszej grupy zasobów. Aby utworzyć nową subskrypcję, musisz utworzyć, ograniczyć zakres i zaimplementować wymagane zasady platformy Azure i role RBAC w subskrypcji docelowej. Celem jest utrzymanie ładu i stanu zabezpieczeń.
W razie potrzeby skonfiguruj nową nazwę domeny. W przypadku zmiany domeny niestandardowej obciążenia należy skonfigurować nową nazwę domeny. Utwórz nową nazwę hosta, przypisz ją do aplikacji lub usługi, a następnie zweryfikuj rozpoznawanie nazw. Możesz również zaplanować obniżenie i skonfigurowanie czasu wygaśnięcia (TTL) i ustawienie go na etapie migracji jednorazowej na potrzeby automatycznego wygaśnięcia. Aby uzyskać więcej informacji, zobacz Dodawanie domeny niestandardowej i Mapuj nazwę DNS do planu usługi App Service.
W razie potrzeby utwórz nowe certyfikaty SSL/TLS. Należy utworzyć nowe certyfikaty SSL/TLS (X.509) dla dowolnej nowej nazwy domeny. Te certyfikaty umożliwiają szyfrowanie kluczy publicznych i bezpieczną komunikację sieciową (HTTPS). Użyj usługi Azure Key Vault, aby utworzyć lub zaimportować certyfikaty X.509. Aby uzyskać więcej informacji, zobacz Azure Key Vault certificates and Certificate creation methods (Certyfikaty usługi Azure Key Vault i metody tworzenia certyfikatów)
Przeniesienie usługi Azure Key Vault. Przed przeniesieniem obciążenia należy przenieść usługę Azure Key Vault. Należy mieć jeden magazyn kluczy na środowisko aplikacji, a magazyn kluczy nie powinien udostępniać wpisów tajnych między regionami w celu zapewnienia poufności. Aby dostosować je do tych wskazówek, może być konieczne utworzenie nowego magazynu kluczy w nowym regionie docelowym.
Utwórz nowy obszar roboczy usługi Log Analytics. Należy mieć oddzielny obszar roboczy usługi Log Analytics dla każdego regionu. Utwórz nowy obszar roboczy w regionie docelowym. Ponieważ nie można przenieść obszaru roboczego usługi Log Analytics do innego regionu, musisz utworzyć nowy obszar roboczy usługi Log Analytics w regionie docelowym. Istnieją dwie opcje zachowania danych w oryginalnym obszarze roboczym. Możesz zachować bieżący obszar roboczy, dopóki nie będą potrzebne dane, traktując dane jako tylko do odczytu. Możesz również wyeksportować dane obszaru roboczego do konta magazynu w nowym docelowym regionie świadczenia usługi Azure.
Migrowanie usług
Możesz rozpocząć migrację usług w obciążeniu. Aby wykonać, postępuj zgodnie z dostępnymi wskazówkami dotyczącymi wybranej automatyzacji relokacji. Usługi Azure Resource Mover i Azure Site Recovery zawierają samouczki krok po kroku dotyczące relokacji usług. Aby uzyskać więcej informacji, zobacz:
Szablony infrastruktury jako kodu można tworzyć dla zasobów, których nie można przenosić. Wdrożenia można również wykonywać ręcznie w witrynie Azure Portal. Konkretne kroki, które należy wykonać, zależą od używanych usług platformy Azure i ich konfiguracji. Aby uzyskać więcej informacji, zobacz Infrastructure as code overview (Infrastruktura jako kod — omówienie).
Migrowanie danych
Ten etap jest istotny tylko wtedy, gdy obciążenie wymaga migracji danych. Przeprowadzanie migracji danych przy użyciu wybranej automatyzacji. Przed przejściem jednorazowym do obciążenia w regionie docelowym należy upewnić się, że powiązane dane są zsynchronizowane z regionem źródłowym. Spójność danych jest ważnym aspektem, który wymaga opieki. Poniżej przedstawiono wskazówki dotyczące migrowania danych obciążenia.
Migrowanie danych regionu źródłowego. Podejście do migrowania danych w regionie źródłowym powinno być zgodne z metodą relokacji dla usługi obciążenia. Metody gorące, zimne i ciepłe mają różne procesy zarządzania danymi w regionie źródłowym.
Synchronizowanie danych. Technika synchronizacji zależy od architektury obciążenia i zapotrzebowania aplikacji. Na przykład podczas synchronizacji na żądanie zmiany są pobierane po pierwszym uzyskiwaniu dostępu do danych. Ściąganie i scalanie zmian występuje tylko w przypadkach, gdy istnieje różnica między dostępem do ostatniej i bieżącej aplikacji.
Rozwiązywanie konfliktów synchronizacji. Upewnij się, że dane w lokalizacji źródłowej i docelowej są zsynchronizowane i rozwiąż wszelkie konflikty danych. Chcesz, aby użytkownicy próbowali uzyskać dostęp do dostępnych danych. Na przykład usługa Azure Cosmos DB może serializować współbieżne zapisy, aby zapewnić spójność danych.
Aktualizowanie parametry połączenia
Konfiguracja parametry połączenia zależy od usługi, z którymi nawiązuje połączenie aplikacja. Możesz wyszukać "parametry połączenia" na naszej stronie dokumentacji, aby znaleźć wskazówki dotyczące usługi i użyć tych wskazówek, aby zaktualizować parametry połączenia. Aby uzyskać więcej informacji, zobacz dokumentację techniczną.
Tożsamości zarządzane
Tożsamości zarządzane przypisane przez system mają cykl życia powiązany z zasobem platformy Azure. Dlatego strategia relokacji zasobu platformy Azure określa sposób obsługi tożsamości zarządzanej przypisanej przez system. Jeśli w obiekcie docelowym zostanie utworzone nowe wystąpienie zasobu, musisz przyznać nowej tożsamości zarządzanej przypisanej przez system te same uprawnienia co tożsamość zarządzana przypisana przez system w regionie źródłowym.
Z drugiej strony tożsamość zarządzana przypisana przez użytkownika ma niezależny cykl życia i można zamapować tożsamość zarządzaną przypisaną przez użytkownika na nowy zasób w regionie docelowym. Aby uzyskać więcej informacji, zobacz Omówienie tożsamości zarządzanej.
Następne kroki
Przeprowadzono migrację usług obciążeń i danych. Teraz musisz ukończyć relokację przy użyciu migracji jednorazowej.