Łączność z publicznym punktem końcowym dla Virtual Machines przy użyciu usługi Azure usługa Load Balancer w warstwie Standardowa w scenariuszach wysokiej dostępności oprogramowania SAP

Zakresem tego artykułu jest opisanie konfiguracji, które umożliwią łączność wychodzącą z publicznymi punktami końcowymi. Konfiguracje są głównie w kontekście wysokiej dostępności z pacemaker dla SUSE / RHEL.

Jeśli używasz programu Pacemaker z agentem ogrodzenia platformy Azure w rozwiązaniu o wysokiej dostępności, maszyny wirtualne muszą mieć łączność wychodzącą z interfejsem API zarządzania platformy Azure. W artykule przedstawiono kilka opcji umożliwiających wybranie opcji najlepiej dopasowanej do danego scenariusza.

Omówienie

Podczas implementowania wysokiej dostępności rozwiązań SAP za pośrednictwem klastrowania jeden z niezbędnych składników jest Azure Load Balancer. Platforma Azure oferuje dwie jednostki SKU modułu równoważenia obciążenia: standardowa i podstawowa.

Usługa Azure Load Balancer w warstwie Standardowa oferuje pewne korzyści w porównaniu z modułem równoważenia obciążenia w warstwie Podstawowa. Na przykład działa ona w strefach dostępności platformy Azure, ma lepsze możliwości monitorowania i rejestrowania w celu łatwiejszego rozwiązywania problemów, mniejszego opóźnienia. Funkcja "Porty wysokiej dostępności" obejmuje wszystkie porty, czyli nie jest już konieczne wyświetlenie listy wszystkich pojedynczych portów.

Istnieją pewne ważne różnice między podstawową i standardową jednostkę SKU modułu równoważenia obciążenia platformy Azure. Jednym z nich jest obsługa ruchu wychodzącego do publicznego punktu końcowego. Aby uzyskać pełne porównanie modułu równoważenia obciążenia jednostki SKU w warstwie Podstawowa i Standardowa, zobacz porównanie jednostek SKU Load Balancer.

Gdy maszyny wirtualne bez publicznych adresów IP są umieszczane w puli zaplecza wewnętrznego (bez publicznego adresu IP) standardowego modułu równoważenia obciążenia platformy Azure, nie ma łączności wychodzącej z publicznymi punktami końcowymi, chyba że zostanie wykonana dodatkowa konfiguracja.

Jeśli maszyna wirtualna ma przypisany publiczny adres IP lub maszyna wirtualna znajduje się w puli zaplecza modułu równoważenia obciążenia z publicznym adresem IP, będzie miała łączność wychodzącą z publicznymi punktami końcowymi.

Systemy SAP często zawierają poufne dane biznesowe. Rzadko dopuszczalne jest, aby maszyny wirtualne hostowania systemów SAP były dostępne za pośrednictwem publicznych adresów IP. W tym samym czasie istnieją scenariusze, które wymagają łączności wychodzącej z maszyny wirtualnej do publicznych punktów końcowych.

Przykłady scenariuszy wymagających dostępu do publicznego punktu końcowego platformy Azure to:

  • Agent ogrodzenia platformy Azure wymaga dostępu do management.azure.com i login.microsoftonline.com
  • Azure Backup
  • Azure Site Recovery
  • Używanie publicznego repozytorium do stosowania poprawek systemu operacyjnego
  • Przepływ danych aplikacji SAP może wymagać łączności wychodzącej z publicznym punktem końcowym

Jeśli wdrożenie sap nie wymaga łączności wychodzącej z publicznymi punktami końcowymi, nie musisz implementować dodatkowej konfiguracji. Wystarczy utworzyć wewnętrzną standardową jednostkę SKU Azure Load Balancer dla scenariusza wysokiej dostępności, zakładając, że nie ma również potrzeby łączności przychodzącej z publicznych punktów końcowych.

Uwaga

Jeśli maszyny wirtualne bez publicznych adresów IP są umieszczane w puli zaplecza wewnętrznego (bez publicznego adresu IP) standardowego modułu równoważenia obciążenia platformy Azure, nie będzie żadnych wychodzących połączeń internetowych, chyba że zostanie wykonana dodatkowa konfiguracja, aby umożliwić routing do publicznych punktów końcowych.
Jeśli maszyny wirtualne mają publiczne adresy IP lub znajdują się już w puli zaplecza usługi Azure Load Balancer z publicznym adresem IP, maszyna wirtualna będzie już mieć łączność wychodzącą z publicznymi punktami końcowymi.

Najpierw przeczytaj następujące dokumenty:

Opcja 1. Dodatkowe zewnętrzne usługa Load Balancer w warstwie Standardowa platformy Azure dla połączeń wychodzących z Internetem

Jedną z opcji osiągnięcia łączności wychodzącej z publicznymi punktami końcowymi bez zezwalania na łączność przychodzącą z maszyny wirtualnej z publicznego punktu końcowego jest utworzenie drugiego modułu równoważenia obciążenia z publicznym adresem IP, dodanie maszyn wirtualnych do puli zaplecza drugiego modułu równoważenia obciążenia i zdefiniowanie tylko reguł ruchu wychodzącego.
Użyj sieciowych grup zabezpieczeń , aby kontrolować publiczne punkty końcowe, które są dostępne dla połączeń wychodzących z maszyny wirtualnej.
Aby uzyskać więcej informacji, zobacz Scenariusz 2 w dokumencie Połączenia wychodzące.
Konfiguracja wygląda następująco:

Kontrolowanie łączności z publicznymi punktami końcowymi za pomocą sieciowych grup zabezpieczeń

Istotne zagadnienia

  • Możesz użyć jednej dodatkowej publicznej Load Balancer dla wielu maszyn wirtualnych w tej samej podsieci, aby uzyskać łączność wychodzącą z publicznym punktem końcowym i zoptymalizować koszt
  • Użyj sieciowych grup zabezpieczeń , aby kontrolować, które publiczne punkty końcowe są dostępne z maszyn wirtualnych. Sieciową grupę zabezpieczeń można przypisać do podsieci lub do każdej maszyny wirtualnej. Jeśli to możliwe, użyj tagów usługi , aby zmniejszyć złożoność reguł zabezpieczeń.
  • Standardowy moduł równoważenia obciążenia platformy Azure z publicznym adresem IP i regułami ruchu wychodzącego umożliwia bezpośredni dostęp do publicznego punktu końcowego. Jeśli masz wymagania dotyczące zabezpieczeń firmy, aby cały ruch wychodzący przechodził za pośrednictwem scentralizowanego rozwiązania firmowego do inspekcji i rejestrowania, może nie być w stanie spełnić wymagań w tym scenariuszu.

Porada

Jeśli to możliwe, użyj tagów usługi , aby zmniejszyć złożoność sieciowej grupy zabezpieczeń .

Kroki wdrażania

  1. Tworzenie Load Balancer

    1. W Azure Portal kliknij pozycję Wszystkie zasoby, Dodaj, a następnie wyszukaj Load Balancer
    2. Kliknij pozycję Utwórz
    3. nazwa Load Balancer MyPublicILB
    4. Wybierz pozycję Publiczna jako typ, Standardowa jako jednostka SKU
    5. Wybierz pozycję Utwórz publiczny adres IP i określ nazwę MyPublicILBFrondEndIP
    6. Wybierz strefę nadmiarową jako strefę dostępności
    7. Kliknij pozycję Przejrzyj i utwórz, a następnie kliknij pozycję Utwórz
  2. Utwórz pulę zaplecza MyBackendPoolOfPublicILB i dodaj maszyny wirtualne.

    1. Wybierz sieć wirtualną
    2. Wybierz maszyny wirtualne i ich adresy IP i dodaj je do puli zaplecza
  3. Utwórz reguły ruchu wychodzącego.

     az network lb outbound-rule create --address-pool MyBackendPoolOfPublicILB --frontend-ip-configs MyPublicILBFrondEndIP --idle-timeout 30 --lb-name MyPublicILB --name MyOutBoundRules  --outbound-ports 10000 --enable-tcp-reset true --protocol All --resource-group MyResourceGroup
    
    
  4. Utwórz reguły sieciowej grupy zabezpieczeń, aby ograniczyć dostęp do określonych publicznych punktów końcowych. Jeśli istnieje sieciowa grupa zabezpieczeń, możesz ją dostosować. W poniższym przykładzie pokazano, jak włączyć dostęp do interfejsu API zarządzania platformy Azure:

    1. Przejdź do sieciowej grupy zabezpieczeń
    2. Kliknij pozycję Reguły zabezpieczeń dla ruchu wychodzącego
    3. Dodaj regułę w celu odmowy dostępu wychodzącego do Internetu.
    4. Dodaj regułę zezwalaną na dostęp do usługi AzureCloud z priorytetem niższym niż priorytet reguły w celu odmowy całego dostępu do Internetu.

    Reguły zabezpieczeń ruchu wychodzącego wyglądają następująco:

    Połączenie wychodzące z drugim Load Balancer z publicznym adresem IP

    Aby uzyskać więcej informacji na temat sieciowych grup zabezpieczeń platformy Azure, zobacz Grupy zabezpieczeń .

Opcja 2: Azure Firewall dla połączeń wychodzących z Internetem

Inną opcją osiągnięcia łączności wychodzącej z publicznymi punktami końcowymi bez zezwalania na łączność przychodzącą z maszyny wirtualnej z publicznych punktów końcowych jest użycie Azure Firewall. Azure Firewall jest usługą zarządzaną z wbudowaną wysoką dostępnością i może obejmować wiele Strefy dostępności.
Należy również wdrożyć trasę zdefiniowaną przez użytkownika skojarzona z podsiecią, w której są wdrażane maszyny wirtualne i moduł równoważenia obciążenia platformy Azure, wskazując na zaporę platformy Azure, aby kierować ruch przez Azure Firewall.
Aby uzyskać szczegółowe informacje na temat wdrażania Azure Firewall, zobacz Wdrażanie i konfigurowanie Azure Firewall.

Architektura wygląda następująco:

Połączenie wychodzące z Azure Firewall

Istotne zagadnienia

  • Usługa Azure Firewall to natywna usługa w chmurze z wbudowaną wysoką dostępnością i obsługuje wdrożenie strefowe.
  • Wymaga dodatkowej podsieci o nazwie AzureFirewallSubnet.
  • W przypadku przenoszenia dużych zestawów danych wychodzących z sieci wirtualnej, w której znajdują się maszyny wirtualne SAP, do maszyny wirtualnej w innej sieci wirtualnej lub do publicznego punktu końcowego, rozwiązanie może nie być opłacalne. Jednym z takich przykładów jest kopiowanie dużych kopii zapasowych w sieciach wirtualnych. Aby uzyskać szczegółowe informacje, zobacz Azure Firewall cennik.
  • Jeśli rozwiązanie zapory firmowej nie jest Azure Firewall i masz wymagania dotyczące zabezpieczeń, aby cały ruch wychodzący przechodził, choć scentralizowane rozwiązanie firmowe, to rozwiązanie może nie być praktyczne.

Porada

Jeśli to możliwe, użyj tagów usługi, aby zmniejszyć złożoność reguł Azure Firewall.

Kroki wdrażania

  1. W krokach wdrażania założono, że masz już sieć wirtualną i podsieć zdefiniowaną dla maszyn wirtualnych.

  2. Utwórz podsieć AzureFirewallSubnet w tej samej Virtual Network, w której są wdrażane maszyny wirtualne i usługa Load Balancer w warstwie Standardowa.

    1. W Azure Portal przejdź do Virtual Network: kliknij pozycję Wszystkie zasoby, wyszukaj Virtual Network, kliknij Virtual Network, wybierz podsieci.
    2. Kliknij pozycję Dodaj podsieć. W polu Nazwa wprowadź wartość AzureFirewallSubnet . Wprowadź odpowiedni zakres adresów. Zapisz zmiany.
  3. Utwórz Azure Firewall.

    1. W Azure Portal wybierz pozycję Wszystkie zasoby, kliknij pozycję Dodaj, Zapora, Utwórz. Wybierz pozycję Grupa zasobów (wybierz tę samą grupę zasobów, w której znajduje się Virtual Network).
    2. Wprowadź nazwę zasobu Azure Firewall. Na przykład MyAzureFirewall.
    3. Wybierz pozycję Region i wybierz co najmniej dwie strefy dostępności zgodne ze strefami dostępności, w których są wdrażane maszyny wirtualne.
    4. Wybierz Virtual Network, w którym są wdrażane maszyny wirtualne SAP i moduł równoważenia obciążenia w warstwie Standardowa.
    5. Publiczny adres IP: kliknij pozycję Utwórz i wprowadź nazwę. Na przykład MyFirewallPublicIP.
  4. Utwórz regułę Azure Firewall, aby zezwolić na łączność wychodzącą z określonymi publicznymi punktami końcowymi. W przykładzie pokazano, jak zezwolić na dostęp do publicznego punktu końcowego interfejsu API usługi Azure Management.

    1. Wybierz pozycję Reguły, Kolekcja reguł sieciowych, a następnie kliknij pozycję Dodaj kolekcję reguł sieciowych.
    2. Nazwa: MyOutboundRule, wprowadź priorytet, wybierz pozycję Zezwalaj na akcję.
    3. Usługa: nazwa toAzureAPI. Protokół: wybierz dowolny. Adres źródłowy: wprowadź zakres dla podsieci, gdzie maszyny wirtualne i usługa Load Balancer w warstwie Standardowa są wdrażane na przykład: 11.97.0.0/24. Porty docelowe: wprowadź wartość *.
    4. Zapisz
    5. Gdy nadal jesteś umieszczony na Azure Firewall, wybierz pozycję Przegląd. Zanotuj prywatny adres IP Azure Firewall.
  5. Tworzenie trasy do Azure Firewall

    1. W Azure Portal wybierz pozycję Wszystkie zasoby, a następnie kliknij pozycję Dodaj, Tabela tras, Utwórz.
    2. Wprowadź nazwę MyRouteTable, wybierz pozycję Subskrypcja, Grupa zasobów i Lokalizacja (pasująca do lokalizacji sieci wirtualnej i zapory).
    3. Zapisz

    Reguła zapory wygląda następująco: Diagram przedstawiający wygląd zapory.

  6. Utwórz trasę zdefiniowaną przez użytkownika z podsieci maszyn wirtualnych do prywatnego adresu IP usługi MyAzureFirewall.

    1. Po ustawieniu pozycji w tabeli tras kliknij pozycję Trasy. Wybierz pozycję Dodaj.
    2. Nazwa trasy: ToMyAzureFirewall, prefiks adresu: 0.0.0.0/0. Typ następnego przeskoku: wybierz pozycję Urządzenie wirtualne. Adres następnego przeskoku: wprowadź prywatny adres IP skonfigurowanej zapory: 11.97.1.4.
    3. Zapisz

Opcja 3. Używanie serwera proxy dla wywołań pacemaker do interfejsu API usługi Azure Management

Możesz użyć serwera proxy, aby zezwolić na wywołania programu Pacemaker do publicznego punktu końcowego interfejsu API zarządzania platformy Azure.

Istotne zagadnienia

  • Jeśli istnieje już firmowy serwer proxy, możesz kierować połączenia wychodzące do publicznych punktów końcowych za pośrednictwem niego. Wywołania wychodzące do publicznych punktów końcowych przejdą przez punkt kontrolny firmy.
  • Upewnij się, że konfiguracja serwera proxy zezwala na łączność wychodzącą z interfejsem API zarządzania platformy Azure: https://management.azure.com i https://login.microsoftonline.com
  • Upewnij się, że istnieje trasa z maszyn wirtualnych do serwera proxy
  • Serwer proxy będzie obsługiwać tylko wywołania HTTP/HTTPS. Jeśli istnieje dodatkowa potrzeba wykonania wywołań wychodzących do publicznego punktu końcowego za pośrednictwem różnych protokołów (takich jak RFC), konieczne będzie rozwiązanie alternatywne
  • Rozwiązanie serwera proxy musi być wysoce dostępne, aby uniknąć niestabilności klastra Pacemaker
  • W zależności od lokalizacji serwera proxy może to spowodować dodatkowe opóźnienie wywołań z agenta ogrodzenia platformy Azure do interfejsu API usługi Azure Management. Jeśli serwer proxy firmy jest nadal w środowisku lokalnym, podczas gdy klaster Pacemaker znajduje się na platformie Azure, zmierz opóźnienie i rozważ, czy to rozwiązanie jest odpowiednie dla Ciebie
  • Jeśli nie ma jeszcze serwera proxy firmowego o wysokiej dostępności, nie zalecamy tej opcji, ponieważ klient będzie ponosił dodatkowe koszty i złożoność. Niemniej jednak jeśli zdecydujesz się wdrożyć dodatkowe rozwiązanie serwera proxy, aby umożliwić łączność wychodzącą z usługi Pacemaker do publicznego interfejsu API usługi Azure Management, upewnij się, że serwer proxy jest wysoce dostępny, a opóźnienie z maszyn wirtualnych do serwera proxy jest niskie.

Konfiguracja programu Pacemaker z serwerem proxy

Istnieje wiele różnych opcji serwera proxy dostępnych w branży. Instrukcje krok po kroku dotyczące wdrażania serwera proxy wykraczają poza zakres tego dokumentu. W poniższym przykładzie przyjęto założenie, że serwer proxy odpowiada na usługę MyProxyService i nasłuchuje portu MyProxyPort.
Aby umożliwić programowi pacemaker komunikowanie się z interfejsem API zarządzania platformą Azure, wykonaj następujące kroki we wszystkich węzłach klastra:

  1. Edytuj plik konfiguracji programu pacemaker /etc/sysconfig/pacemaker i dodaj następujące wiersze (wszystkie węzły klastra):

    sudo vi /etc/sysconfig/pacemaker
    # Add the following lines
    http_proxy=http://MyProxyService:MyProxyPort
    https_proxy=http://MyProxyService:MyProxyPort
    
  2. Uruchom ponownie usługę pacemaker we wszystkich węzłach klastra.

  • SUSE

    # Place the cluster in maintenance mode
    sudo crm configure property maintenance-mode=true
    #Restart on all nodes
    sudo systemctl restart pacemaker
    # Take the cluster out of maintenance mode
    sudo crm configure property maintenance-mode=false
    
  • Red Hat

    # Place the cluster in maintenance mode
    sudo pcs property set maintenance-mode=true
    #Restart on all nodes
    sudo systemctl restart pacemaker
    # Take the cluster out of maintenance mode
    sudo pcs property set maintenance-mode=false
    

Inne opcje

Jeśli ruch wychodzący jest kierowany za pośrednictwem innej firmy, serwer proxy zapory oparty na adresach URL:

  • jeśli używasz agenta ogrodzenia platformy Azure, upewnij się, że konfiguracja zapory zezwala na łączność wychodzącą z interfejsem API zarządzania platformy Azure: https://management.azure.com i https://login.microsoftonline.com
  • jeśli używasz infrastruktury aktualizacji chmury publicznej platformy Azure platformy SUSE do stosowania aktualizacji i poprawek, zobacz Azure Public Cloud Update Infrastructure 101

Następne kroki