Zachowaj adresy IP podczas trybu failover

Usługa Azure Site Recovery umożliwia odzyskiwanie po awarii dla maszyn wirtualnych platformy Azure przez replikowanie maszyn wirtualnych do innego regionu świadczenia usługi Azure, przełączanie w tryb failover w przypadku wystąpienia awarii i powrót po awarii do regionu podstawowego, gdy elementy wracają do normalnego stanu.

Podczas pracy w trybie failover możesz zachować adresowanie IP w regionie docelowym identycznym z regionem źródłowym:

• Domyślnie po włączeniu odzyskiwania po awarii dla maszyn wirtualnych platformy Azure usługa Site Recovery tworzy zasoby docelowe na podstawie ustawień zasobów źródłowych. W przypadku maszyn wirtualnych platformy Azure skonfigurowanych przy użyciu statycznych adresów IP usługa Site Recovery próbuje aprowizować ten sam adres IP dla docelowej maszyny wirtualnej, jeśli nie jest używana. Aby uzyskać pełne wyjaśnienie sposobu obsługi adresowania przez usługę Site Recovery, zapoznaj się z tym artykułem.
• W przypadku prostych aplikacji domyślna konfiguracja jest wystarczająca. W przypadku bardziej złożonych aplikacji może być konieczne aprowizowania dodatkowego zasobu, aby upewnić się, że łączność działa zgodnie z oczekiwaniami po przejściu w tryb failover.

Ten artykuł zawiera kilka przykładów dotyczących przechowywania adresów IP w bardziej złożonych przykładowych scenariuszach. Przykłady obejmują:

• Przechodzenie w tryb failover dla firmy ze wszystkimi zasobami uruchomionymi na platformie Azure
• Tryb failover dla firmy z wdrożeniem hybrydowym i zasobami działającymi zarówno lokalnie, jak i na platformie Azure

Zasoby na platformie Azure: pełny tryb failover

Firma A ma wszystkie swoje aplikacje uruchomione na platformie Azure.

Przed przejściem w tryb failover

Uwaga

Replikację można teraz przeprowadzić między dwoma regionami świadczenia usługi Azure na całym świecie. Klienci nie są już ograniczeni do włączania replikacji na ich kontynencie.

Oto architektura przed przejściem w tryb failover.

• Firma A ma identyczne sieci i podsieci w regionach źródłowych i docelowych platformy Azure.
• Aby skrócić cel czasu odzyskiwania (RTO), firma używa węzłów repliki dla zawsze włączonego programu SQL Server, kontrolerów domeny itp. Te węzły repliki znajdują się w innej sieci wirtualnej w regionie docelowym, dzięki czemu mogą ustanowić łączność lokacja-lokacja sieci VPN między regionami źródłowymi i docelowymi. Nie jest to możliwe, jeśli ta sama przestrzeń adresowa IP jest używana w źródle i miejscu docelowym.
• Przed przejściem w tryb failover architektura sieci wygląda następująco:
  • Region podstawowy to Azure East Asia
    • Azja Wschodnia ma sieć wirtualną (źródłową sieć wirtualną) z przestrzenią adresową 10.1.0.0/16.
    • Azja Wschodnia ma obciążenia podzielone między trzy podsieci w sieci wirtualnej:
      • Podsieć 1: 10.1.1.0/24
      • Podsieć 2: 10.1.2.0/24
      • Podsieć 3: 10.1.3.0/24
  • Region pomocniczy (docelowy) to Azure Południowo-Wschodnia Azja Południowo-Wschodnia
    • Azja Południowo-Wschodnia ma sieć wirtualną odzyskiwania (recovery VNet) identyczną z źródłową siecią wirtualną.
    • Azja Południowo-Wschodnia ma dodatkową sieć wirtualną (Azure VNet) z przestrzenią adresową 10.2.0.0/16.
    • Sieć wirtualna platformy Azure zawiera podsieć (podsieć 4) z przestrzenią adresową 10.2.4.0/24.
    • Węzły repliki dla zawsze włączonego programu SQL Server, kontrolera domeny itp. znajdują się w podsieci Subnet 4.
  • Źródłowa sieć wirtualna i sieć wirtualna platformy Azure są połączone z połączeniem typu lokacja-lokacja sieci VPN.
  • Sieć wirtualna odzyskiwania nie jest połączona z żadną inną siecią wirtualną.
  • Firma A przypisuje/weryfikuje docelowe adresy IP dla replikowanych elementów. Docelowy adres IP jest taki sam jak źródłowy adres IP dla każdej maszyny wirtualnej.

Po przejściu w tryb failover

Jeśli wystąpi awaria regionalna źródła, firma A może przejąć wszystkie zasoby w tryb failover do regionu docelowego.

• Jeśli docelowe adresy IP są już dostępne przed przejściem w tryb failover, firma A może organizować tryb failover i automatycznie nawiązywać połączenia po przejściu w tryb failover między siecią wirtualną odzyskiwania a siecią wirtualną platformy Azure. Przedstawiono to na poniższym diagramie.
• W zależności od wymagań aplikacji połączenia między dwiema sieciami wirtualnymi (odzyskiwana sieć wirtualna i sieć wirtualna platformy Azure) w regionie docelowym można ustanowić przed (w ramach pośredniego kroku) lub po przejściu w tryb failover.

  • Firma może użyć planów odzyskiwania, aby określić, kiedy zostaną nawiązane połączenia.

  • Mogą łączyć się między sieciami wirtualnymi przy użyciu komunikacji równorzędnej sieci wirtualnych lub sieci VPN typu lokacja-lokacja.

    • W przypadku wirtualnych sieci równorzędnych nie jest używana brama sieci VPN i występują inne ograniczenia.
    • Cennik komunikacji równorzędnej sieci wirtualnych jest obliczany inaczej niż cennik usługi VPN Gateway między sieciami wirtualnymi. W przypadku trybu failover zalecamy użycie tej samej metody łączności co sieci źródłowe, w tym typu połączenia, w celu zminimalizowania nieprzewidywalnych zdarzeń sieciowych.

    

Zasoby na platformie Azure: tryb failover izolowanej aplikacji

Może być konieczne przełączenie w tryb failover na poziomie aplikacji. Na przykład w celu przejścia w tryb failover określonej aplikacji lub warstwy aplikacji znajdującej się w dedykowanej podsieci.

• W tym scenariuszu mimo że można zachować adresowanie IP, zwykle nie jest to zalecane, ponieważ zwiększa prawdopodobieństwo niespójności łączności. Utracisz również łączność podsieci z innymi podsieciami w tej samej sieci wirtualnej platformy Azure.
• Lepszym sposobem pracy w trybie failover aplikacji na poziomie podsieci jest użycie różnych docelowych adresów IP na potrzeby trybu failover (jeśli potrzebujesz łączności z innymi podsieciami w źródłowej sieci wirtualnej) lub odizolowania każdej aplikacji we własnej dedykowanej sieci wirtualnej w regionie źródłowym. Dzięki temu drugiemu podejściu można ustanowić łączność między sieciami w regionie źródłowym i emulować to samo zachowanie podczas przechodzenia w tryb failover do regionu docelowego.

W tym przykładzie firma A umieszcza aplikacje w regionie źródłowym w dedykowanych sieciach wirtualnych i ustanawia łączność między tymi sieciami wirtualnymi. Dzięki temu projektowi mogą wykonywać izolowane przejście w tryb failover aplikacji i zachować źródłowe prywatne adresy IP w sieci docelowej.

Przed przejściem w tryb failover

Przed przejściem w tryb failover architektura jest następująca:

• Maszyny wirtualne aplikacji są hostowane w podstawowym regionie Azji Wschodniej platformy Azure:

  • Maszyny wirtualne App1 znajdują się w źródłowej sieci wirtualnej 1: 10.1.0.0/16.
  • Maszyny wirtualne App2 znajdują się w źródłowej sieci wirtualnej 2: 10.2.0.0/16.
  • Źródłowa sieć wirtualna 1 ma dwie podsieci.
  • Źródłowa sieć wirtualna 2 ma dwie podsieci.

• Region pomocniczy (docelowy) to Azja Południowo-Wschodnia — Azja Południowo-Wschodnia ma sieci wirtualne odzyskiwania (recovery VNet 1 i Recovery VNet 2), które są identyczne z źródłowymi sieciami wirtualnymi 1 i źródłowymi sieciami wirtualnymi 2. - Sieć wirtualna odzyskiwania 1 i sieć wirtualna odzyskiwania 2 mają dwie podsieci zgodne z podsieciami w źródłowej sieci wirtualnej 1 i źródłowej sieci wirtualnej 2 — Azja Południowo-Wschodnia ma dodatkową sieć wirtualną (sieć wirtualną Platformy Azure) z przestrzenią adresową 10.3.0.0/16. - Sieć wirtualna platformy Azure zawiera podsieć (podsieć 4) z przestrzenią adresową 10.3.4.0/24. — Węzły repliki dla zawsze włączonego programu SQL Server, kontrolera domeny itp. znajdują się w podsieci Subnet 4.

• Istnieje wiele połączeń sieci VPN typu lokacja-lokacja:

  • Źródłowa sieć wirtualna 1 i sieć wirtualna platformy Azure
  • Źródłowa sieć wirtualna 2 i sieć wirtualna platformy Azure
  • Źródłowa sieć wirtualna 1 i źródłowa sieć wirtualna 2 są połączone z siecią VPN typu lokacja-lokacja

• Sieć wirtualna odzyskiwania 1 i sieć wirtualna odzyskiwania 2 nie są połączone z żadną inną siecią wirtualną.

• Firma A konfiguruje bramy sieci VPN w sieci wirtualnej odzyskiwania 1 i odzyskiwania sieci wirtualnej 2 w celu zmniejszenia celu czasu odzyskiwania.

• Sieć VNet1 odzyskiwania i sieć wirtualna odzyskiwania 2 nie są połączone z żadną inną siecią wirtualną.

• Aby skrócić cel czasu odzyskiwania (RTO), bramy sieci VPN są konfigurowane w sieci VNet1 odzyskiwania i odzyskiwania VNet2 przed przejściem w tryb failover.

  

Po przejściu w tryb failover

W przypadku awarii lub problemu, który ma wpływ na jedną aplikację (w **Źródłowej sieci wirtualnej 2 w naszym przykładzie), firma A może odzyskać aplikację, której dotyczy problem, w następujący sposób:

• Rozłącz połączenia sieci VPN między źródłową siecią VNet1 i źródłową siecią VNet2 oraz między siecią źródłową VNet2 i siecią wirtualną platformy Azure.
• Ustanów połączenia sieci VPN między źródłową siecią VNet1 i siecią wirtualną odzyskiwania 2 oraz między siecią wirtualną usługi Recovery VNet2 i platformą Azure.
• Maszyny wirtualne w trybie failover w źródłowej sieci VNet2 do odzyskiwania sieci VNet2.

• Ten przykład można rozszerzyć, aby uwzględnić więcej aplikacji i połączeń sieciowych. Zaleca się, aby postępować zgodnie z modelem połączenia przypominającym, jak to możliwe, w przypadku przechodzenia w tryb failover z źródła do celu.
• Bramy sieci VPN używają publicznych adresów IP i przeskoków bramy do nawiązywania połączeń. Jeśli nie chcesz używać publicznych adresów IP lub chcesz uniknąć dodatkowych przeskoków, możesz użyć komunikacji równorzędnej sieci wirtualnych platformy Azure do komunikacji równorzędnej sieci wirtualnych w obsługiwanych regionach świadczenia usługi Azure.

Zasoby hybrydowe: pełny tryb failover

W tym scenariuszu firma B prowadzi hybrydową firmę z częścią infrastruktury aplikacji uruchomionej na platformie Azure i resztą działającą lokalnie.

Przed przejściem w tryb failover

Oto jak wygląda architektura sieci przed przejściem w tryb failover.

• Maszyny wirtualne aplikacji są hostowane w Azji Wschodniej platformy Azure.
• Azja Wschodnia ma sieć wirtualną (źródłową sieć wirtualną) z przestrzenią adresową 10.1.0.0/16.
  • Azja Wschodnia ma obciążenia podzielone na trzy podsieci w źródłowej sieci wirtualnej:
    • Podsieć 1: 10.1.1.0/24
    • Podsieć 2: 10.1.2.0/24
    • Podsieć 3: 10.1.3.0/24, korzystając z sieci wirtualnej platformy Azure z przestrzenią adresową 10.1.0.0/16. Ta sieć wirtualna nosi nazwę Źródłowa sieć wirtualna
• Region pomocniczy (docelowy) to Azja Południowo-Wschodnia platformy Azure:
  • Azja Południowo-Wschodnia ma sieć wirtualną odzyskiwania (recovery VNet) identyczną z źródłową siecią wirtualną.
• Maszyny wirtualne w Azji Wschodniej są połączone z lokalnym centrum danych za pomocą usługi Azure ExpressRoute lub sieci VPN typu lokacja-lokacja.
• Aby zmniejszyć cel czasu odzyskiwania, firma B aprowizuje bramy w sieci wirtualnej odzyskiwania w Azji Południowo-Wschodniej platformy Azure przed przejściem w tryb failover.
• Firma B przypisuje/weryfikuje docelowe adresy IP dla replikowanych maszyn wirtualnych. Docelowy adres IP jest taki sam jak źródłowy adres IP dla każdej maszyny wirtualnej.

Po przejściu w tryb failover

Jeśli wystąpi awaria regionalna źródła, firma B może przejąć wszystkie zasoby w tryb failover do regionu docelowego.

• Jeśli docelowe adresy IP są już w miejscu przed przejściem w tryb failover, firma B może organizować tryb failover i automatycznie nawiązywać połączenia po przejściu w tryb failover między siecią wirtualną odzyskiwania i siecią wirtualną platformy Azure.
• W zależności od wymagań aplikacji połączenia między dwiema sieciami wirtualnymi (odzyskiwana sieć wirtualna i sieć wirtualna platformy Azure) w regionie docelowym można ustanowić przed (w ramach pośredniego kroku) lub po przejściu w tryb failover. Firma może użyć planów odzyskiwania, aby określić, kiedy zostaną nawiązane połączenia.
• Oryginalne połączenie między Azją Wschodnią platformy Azure a lokalnym centrum danych powinno zostać rozłączone przed nawiązaniem połączenia między azja południowo-wschodnią platformą Azure i lokalnym centrum danych.
• Routing lokalny jest ponownie skonfigurowany tak, aby wskazywał region docelowy i bramy po przejściu w tryb failover.

Zasoby hybrydowe: tryb failover izolowanej aplikacji

Firma B nie może przejąć aplikacji izolowanych w trybie failover na poziomie podsieci. Dzieje się tak, ponieważ przestrzeń adresowa w źródłowych i odzyskiwania sieciach wirtualnych jest taka sama, a oryginalne źródło połączenia lokalnego jest aktywne.

• W przypadku odporności aplikacji firma B musi umieścić każdą aplikację we własnej dedykowanej sieci wirtualnej platformy Azure.
• W przypadku każdej aplikacji w oddzielnej sieci wirtualnej firma B może przejąć izolowane aplikacje w tryb failover i kierować połączenia źródłowe do regionu docelowego.

Następne kroki

Dowiedz się więcej o planach odzyskiwania.