Udostępnij za pośrednictwem

Konfigurowanie grup dostępności Always On i wystąpień klastrów przełączających się awaryjnie z wieloma podsieciami

  • Artykuł

Dotyczy:programu SQL Server — Linux

Gdy grupa dostępności Always On (AG) lub wystąpienie klastra trybu failover (FCI) obejmuje więcej niż jedną lokalizację, każda lokalizacja zwykle ma własną sieć, co często oznacza, że każda lokalizacja ma własny schemat adresowania IP.

Na przykład adresy lokalizacji A zaczynają się od 192.168.1.<x>, a adresy lokalizacji B zaczynają się od 192.168.2.<x>, gdzie <x> jest częścią adresu IP, który jest unikalny dla serwera. Bez pewnego rodzaju routingu w warstwie sieciowej te serwery nie są w stanie komunikować się ze sobą.

Istnieją dwa sposoby obsługi tego scenariusza:

  • Konfigurowanie sieci, która łączy dwie różne podsieci (znane jako sieć VLAN)
  • konfigurowanie routingu między podsieciami

Rozwiązanie oparte na sieci VLAN

Wymagania wstępne: W przypadku rozwiązania opartego na sieci VLAN każdy serwer uczestniczący w grupie dostępności (AG) lub instancji klastra trybu awaryjnego (FCI) wymaga dwóch kart sieciowych (NIC), aby zapewnić odpowiednią dostępność (karta sieciowa z podwójnym portem byłaby pojedynczym punktem awarii na serwerze fizycznym), tak aby można mu przypisać adresy IP zarówno na jego natywnej podsieci, jak i na sieci VLAN. To wymaganie jest oprócz innych potrzeb sieci, takich jak iSCSI, które również potrzebuje własnej sieci.

Tworzenie adresu IP dla grupy dostępności lub wystąpienia klastra trybu failover odbywa się na sieci VLAN. W poniższym przykładzie sieć VLAN ma podsieć 192.168.3.<x>, więc adres IP utworzony dla AG lub FCI to 192.168.3.104. Nie trzeba konfigurować żadnych dodatkowych elementów, ponieważ przypisany jest tylko jeden adres IP do AG (grupy dostępności) lub FCI (wystąpienia klastra trybu failover).

Diagram przedstawiający sposób konfigurowania wielu podsieci za pomocą sieci VLAN.

Konfiguracja za pomocą programu Pacemaker

W systemie Windows klaster trybu failover systemu Windows Server (WSFC) natywnie obsługuje wiele podsieci i obsługuje wiele adresów IP za pośrednictwem zależności OR od adresu IP. W systemie Linux nie ma zależności OR, ale istnieje sposób na natywne osiągnięcie odpowiedniej konfiguracji wielosieci z użyciem Pacemaker, chociaż nie można użyć standardowego interfejsu wiersza poleceń Pacemaker. Zamiast tego należy zmodyfikować bazę informacji o klastrze (CIB). CiB to plik XML z konfiguracją programu Pacemaker.

Diagram przedstawiający sposób konfigurowania wielu podsieci za pomocą programu Pacemaker.

Aktualizacja CIB

  • Red Hat Enterprise Linux (RHEL)
  • SUSE Linux Enterprise Server (SLES)
  • ubuntu

  1. Wyeksportuj CIB.

    sudo pcs cluster cib <filename>

    Gdzie <filename> to nazwa, którą chcesz nadać CIB.

  2. Edytuj wygenerowany plik. Wyszukaj sekcję <resources>. Zobaczysz różne zasoby utworzone dla AG (grupy dostępności) lub FCI (wystąpienia klastra trybu failover). Znajdź ten skojarzony z adresem IP. Dodaj sekcję <instance_attributes> z informacjami o drugim adresie IP, umieszczając ją przed lub po istniejącej sekcji, ale koniecznie przed <operations>. Jest podobna do następującej składni:

    <instance_attributes id="<NameForAttribute>">
    <nvpair id="<NameForIP>" name="ip" value="<IPAddress>"/>
</instance_attributes>

    gdzie <NameForAttribute> jest unikatową nazwą tego atrybutu, <NameForIP> jest nazwą skojarzona z adresem IP, <IPAddress> jest adresem IP drugiej podsieci.

    Poniżej przedstawiono przykład.

    <instance_attributes id="virtualip-instance_attributes">
    <nvpair id="virtualip-instance_attributes-ip" name="ip" value="192.168.1.102"/>
</instance_attributes>

    Domyślnie w wyeksportowanym pliku XML CIB jest tylko jeden <instance_attributes />. Jeśli istnieją dwie podsieci, potrzebne są dwa <instance_attributes /> wpisy.

    Oto przykład wpisów dla dwóch podsieci:

    <instance_attributes id="virtualip-instance_attributes1">
    <rule id="Subnet1-IP" score="INFINITY" boolean-op="or">
        <expression id="Subnet1-Node1" attribute="#uname" operation="eq" value="Node1" />
        <expression id="Subnet1-Node2" attribute="#uname" operation="eq" value="Node2" />
    </rule>
    <nvpair id="IP-In-Subnet1" name="ip" value="192.168.1.102"/>
</instance_attributes>
<instance_attributes id="virtualip-instance_attributes2">
    <rule id="Subnet2-IP" score="INFINITY">
        <expression id="Subnet2-Node1" attribute="#uname" operation="eq" value="Node3" />
    </rule>
    <nvpair id="IP-In-Subnet2" name="ip" value="192.168.2.102"/>
</instance_attributes>

    Należy użyć boolean-op="or", gdy podsieć ma więcej niż jeden serwer.

  3. Zaimportuj zmodyfikowany ciB i skonfiguruj ponownie program Pacemaker.

    sudo pcs cluster cib-push <filename>

    Gdzie <filename> jest nazwą pliku CIB ze zmodyfikowanymi informacjami o adresie IP.

Sprawdzanie i weryfikowanie trybu failover

  1. Po pomyślnym zastosowaniu modelu CIB ze zaktualizowaną konfiguracją wyślij polecenie ping do nazwy DNS skojarzonej z zasobem adresu IP w programie Pacemaker. Powinno to odzwierciedlać adres IP skojarzony z podsiecią, która obecnie hostuje AG lub FCI.

  2. Nieudane przełączenie AG lub FCI na inną podsieć.

  3. Gdy AG lub FCI są w pełni dostępne, wykonaj ping nazwy DNS skojarzonej z adresem IP. Powinien on odzwierciedlać adres IP w drugiej podsieci.

  4. Jeśli to pożądane, przywróć grupę dostępności (AG) lub instancję klastrową trybu failover (FCI) do oryginalnej podsieci.

Powiązana zawartość