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, przechodzenie w tryb failover w przypadku wystąpienia awarii i powrót po awarii do regionu podstawowego, gdy wszystko wróci do normalnego.

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 Site Recovery tworzy zasoby docelowe na podstawie ustawień zasobów źródłowych. W przypadku maszyn wirtualnych platformy Azure skonfigurowanych ze statycznymi adresami IP Site Recovery próbuje aprowizować ten sam adres IP docelowej maszyny wirtualnej, jeśli nie jest używany. Aby zapoznać się z pełnym wyjaśnieniem sposobu obsługi adresowania przez 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 przechowywania adresów IP w bardziej złożonych scenariuszach przykładowych. Przykłady obejmują:

• Tryb failover dla firmy ze wszystkimi zasobami działającymi 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 działające na platformie Azure.

Przed przejściem w tryb failover

Uwaga

Replikację można teraz wykonać między dwoma regionami platformy 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 do SQL Server Zawsze włączone, kontrolery 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 obiekcie docelowym.
• Przed przejściem w tryb failover architektura sieci jest następująca:
  • 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 na 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 Azja Południowo-Wschodnia Azure
    • Azja Południowo-Wschodnia ma sieć wirtualną odzyskiwania (Recovery VNet) identyczną z siecią wirtualną źródłową.
    • Azja Południowo-Wschodnia ma dodatkową sieć wirtualną (sieć wirtualną platformy Azure) 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 SQL Server Always On, kontroler 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.

• W przypadku docelowych adresów IP już w miejscu przed przejściem w tryb failover firma A może organizować tryb failover i automatycznie ustanowić połączenia po przejściu w tryb failover między siecią wirtualną odzyskiwania i siecią wirtualną platformy Azure. Przedstawiono to na poniższym diagramie.
• W zależności od wymagań aplikacji połączenia między dwiema sieciami wirtualnymi (sieć wirtualna odzyskiwania i sieć wirtualna platformy Azure) w regionie docelowym można ustanowić wcześniej podczas (jako krok pośredni) 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.
    • Ceny komunikacji równorzędnej sieci wirtualnych są obliczane inaczej niż w przypadku cen VPN Gateway sieci wirtualnych. 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, chociaż można zachować adresowanie IP, zazwyczaj 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 przejścia w tryb failover aplikacji na poziomie podsieci jest użycie różnych docelowych adresów IP w trybie 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 po przejściu 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 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:

  • App1 Maszyny wirtualne znajdują się w źródłowej sieci wirtualnej 1: 10.1.0.0/16.
  • App2 Maszyny wirtualne 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 SQL Server Always On, kontroler 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 innymi sieciami wirtualnymi.

• Firma A konfiguruje bramy sieci VPN w sieci wirtualnej recovery 1 i recovery VNet 2, aby zmniejszyć cel czasu odzyskiwania.

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

• Aby zmniejszyć cel czasu odzyskiwania (RTO), bramy sieci VPN są konfigurowane w sieci VNet1 odzyskiwania i w sieci 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 źródłową siecią wirtualną VNet2 i siecią wirtualną platformy Azure .
• Ustanów połączenia sieci VPN między źródłową siecią VNet1 i siecią wirtualną usługi Recovery VNet2 oraz między siecią wirtualną usługi Recovery VNet2 i siecią wirtualną platformy Azure.
• Przełączanie maszyn wirtualnych w tryb failover w źródłowej sieci VNet2 do usługi Recovery VNet2.

• Ten przykład można rozszerzyć, aby uwzględnić więcej aplikacji i połączeń sieciowych. Zaleceniem jest użycie modelu połączenia przypominającego podobieństwo, o ile to możliwe, w przypadku przechodzenia w tryb failover ze źródła na docelowy.
• 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 równorzędnych sieci wirtualnych w obsługiwanych regionach świadczenia usługi Azure.

Zasoby hybrydowe: pełny tryb failover

W tym scenariuszu firma B prowadzi działalność hybrydową z częścią infrastruktury aplikacji działającej na platformie Azure i pozostałymi uruchomionymi 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 Azure Południowo-Wschodnia Azja:
  • 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 w regionie docelowym.

• Jeśli docelowe adresy IP są już stosowane 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 a siecią wirtualną platformy Azure.
• W zależności od wymagań aplikacji można ustanowić połączenia między dwiema sieciami wirtualnymi (recovery VNet i Azure VNet) w regionie docelowym przed (jako krok pośredni) 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 Azja Wschodnią platformą Azure a lokalnym centrum danych powinno zostać rozłączone przed nawiązaniem połączenia między Azją Południowo-Wschodnią a lokalnym centrum danych.
• Routing lokalny jest ponownie skonfigurowany tak, aby wskazywał docelowy region 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.

• Aby zapewnić odporność aplikacji, firma B będzie musiała umieścić każdą aplikację we własnej dedykowanej sieci wirtualnej platformy Azure.
• Każda aplikacja w oddzielnej sieci wirtualnej umożliwia przechodzenie w tryb failover izolowanych aplikacji oraz kierowanie połączeń źródłowych do regionu docelowego.

Następne kroki

Dowiedz się więcej o planach odzyskiwania.