Wdrażanie świadka w chmurze dla klastra przełączania awaryjnego
Cloud Witness to typ świadka kworum klastra awaryjnego przełączania, który używa platformy Microsoft Azure do głosowania w kworum klastra. Ten artykuł zawiera przegląd funkcji Cloud Witness, opisy scenariuszy, które obsługuje, oraz instrukcje dotyczące konfigurowania Cloud Witness dla klastra typu failover. Aby uzyskać więcej informacji, zobacz Konfigurowanie monitora klastra.
Czym jest Cloud Witness?
Przed rozpoczęciem powinieneś odświeżyć pamięć o tym, czym są kworum klastra i świadkowie kworum, czytając Zrozumienie kworum klastra i puli.
Teraz zacznijmy od przyjrzenia się przykładowej konfiguracji kworum wielolokalnego rozciągniętego klastra trybu failover dla systemu Windows Server, pokazanej na poniższym diagramie.
Ten przykład jest uproszczoną konfiguracją z dwoma węzłami w dwóch centrach danych w lokacji. W typowych klastrach każdy węzeł ma jeden głos, świadek udziału plików , który daje jeden dodatkowy głos dla świadka kworum. To dodatkowe głosowanie umożliwia działanie klastra nawet wtedy, gdy jedno z centrów danych zostanie wyłączone. W tym przykładzie kworum klastra ma pięć możliwych głosów i potrzebuje tylko trzech głosów, aby kontynuować pracę.
Można jednak zauważyć, że oprócz dwóch centrów danych, jest również trzecie centrum danych, które działa jako świadek udziału plików . To centrum danych jest oddzielone od pozostałych dwóch miejsc i hostuje serwer plików, który wykonuje kopię zapasową współdzielonego zasobu systemowego. Monitor udziału plików działa jako monitor kworum w tej konfiguracji kworum klastra, upewniając się, że system nadal działa, nawet jeśli jeden z centrów danych nieoczekiwanie zostanie zamknięty.
Posiadanie świadka udziału plików zapewnia wystarczającą nadmiarowość, aby zapewnić wysoką dostępność serwera plików. Należy jednak pamiętać, że hostowanie monitora udziału plików na innym serwerze w oddzielnej lokacji wymaga konfiguracji, regularnej konserwacji i niezależnej łączności z innymi lokacjami.
Cloud Witness różni się od tradycyjnych konfiguracji świadka kworum klastra, ponieważ używa maszyny wirtualnej na platformie Azure w chmurze jako świadka kworum zamiast tradycyjnego centrum danych. Cloud Witness używa usługi Azure Blob Storage do odczytywania i zapisywania pliku blob, który system wykorzystuje jako decydujący głos w celu osiągnięcia kworum. Na poniższym diagramie przedstawiono przykładową konfigurację korzystającą z świadka w chmurze.
Jak widać, konfiguracje Cloud Witness nie wymagają trzeciego, oddzielnego centrum danych. Monitor w chmurze, podobnie jak każdy inny monitor kworum, otrzymuje dodatkowe głosowanie i pomaga zapobiec całkowitym zamykaniom, jeśli jedno z innych centrów danych wyłączy się. Nie potrzebuje jednak dodatkowej witryny do przechowywania świadka kworum. Cloud Witness nie wymaga również regularnej konserwacji fizycznej, jakiej wymaga lokalne centrum danych.
Oprócz zapewnienia redundancji istnieją także inne korzyści wynikające z korzystania z funkcji Cloud Witness.
Do osiągnięcia kworum nie trzeba używać oddzielnego dodatkowego centrum danych.
Korzystanie z usługi Azure Blob Storage eliminuje dodatkowe obciążenie związane z konserwacją zwykle wymagane do hostowania maszyn wirtualnych w chmurze publicznej.
Możesz użyć tego samego konta usługi Azure Storage dla wielu klastrów. Jedynymi wymaganiami są korzystanie tylko z jednego obiektu blob na klaster oraz nazywanie pliku obiektu blob według unikatowego identyfikatora klastra.
Obniż bieżące koszty konta magazynowego, ponieważ plik obiektu blob nie potrzebuje wielu danych i aktualizuje się tylko wtedy, gdy stan węzła klastra się zmienia.
Platforma Azure jest dostarczana z wbudowanym typem zasobu Cloud Witness.
Warunki wstępne
Aby skonfigurować Świadka w Chmurze, musisz mieć konto platformy Azure z aktywną subskrypcją i ważnym kontem magazynu ogólnego zastosowania platformy Azure. To konto magazynowe jest miejscem, gdzie Cloud Witness tworzy kontener msft-cloud-witness do przechowywania pliku blob wymaganego do arbitrażu głosowania.
Notatka
Cloud Witness nie jest zgodny z następującymi typami kont Azure Storage:
- Przechowywanie obiektów BLOB
- Azure Premium Storage
Możesz również użyć tego konta i kontenera msft-cloud-witness, który jest automatycznie tworzony przez Cloud Witness, aby skonfigurować Cloud Witness w wielu różnych klastrach. Każdy klaster ma własny plik blob przechowywany w kontenerze.
Jeśli podczas tworzenia konta usługi Azure Storage klaster, dla którego konfigurujesz Świadka w chmurze, znajduje się lokalnie lub na platformie Azure w tym samym regionie i strefach dostępności platformy Azure, wybierz lokalnie nadmiarową pamięć (LRS) podczas konfigurowania pola Replikacja. Jeśli klaster znajduje się w tym samym regionie świadczenia usługi Azure, ale w różnych strefach dostępności, wybierz magazyn strefowo nadmiarowy (ZRS).
Należy użyć jednego z następujących obsługiwanych scenariuszy:
Odzyskiwanie po awarii dla rozciągniętych klastrów wielolokacyjnych, który jest pokazany w Co to jest Cloud Witness.
Klastry trybu failover bez współdzielonego magazynu, takie jak SQL Always On.
Klastry awaryjne działające wewnątrz systemu operacyjnego gościa, który jest hostowany jako maszyna wirtualna na platformie Microsoft Azure lub w dowolnej innej chmurze publicznej.
Klastry trybu failover składające się z maszyn wirtualnych hostowanych w chmurach prywatnych działających w systemie operacyjnym gościa.
Klastry magazynu z magazynem udostępnionym lub bez niego, takie jak klastry serwerów plików skalowalnych poziomo.
Małe klastry oddziałów, które są nawet klastrami dwuwęźleowymi.
Zalecamy zawsze skonfigurowanie świadka, jeśli używasz systemu Windows Server 2012 R2 lub nowszego. Klastry w nowszych wersjach systemu Windows Server automatycznie zarządzają głosowaniem świadka, a węzły głosują za pomocą dynamicznego kworum.
Należy również upewnić się, że wszystkie zapory między klastrem przełączania awaryjnego a usługą Azure Storage zezwalają na ruch z portu 443, znanego również jako port HTTPS. Cloud Witness używa interfejsu REST protokołu HTTPS dla usługi Azure Storage. W związku z tym musisz mieć otwarty port 443 na wszystkich węzłach w klastrze trybu failover, aby Cloud Witness działał zgodnie z oczekiwaniami.
Podczas tworzenia konta usługi Azure Storage platforma Azure kojarzy je z automatycznie wygenerowanymi podstawowymi i pomocniczymi kluczami dostępu. Podczas konfigurowania Miernika w chmurze po raz pierwszy, zalecamy użycie podstawowego klucza dostępu. Następnie można użyć podstawowego lub pomocniczego klucza dostępu.
Konfiguracja Cloud Witness jako świadka kworum dla klastra
Świadka Chmury można skonfigurować przy użyciu procesu konfiguracji kworum wbudowanego w aplikację Menedżera klastra przełączania awaryjnego lub za pomocą programu PowerShell.
- Menedżer klastra przełączania awaryjnego
- PowerShell
- Windows Admin Center
W menedżerze serwera wybierz Tools, a następnie wybierz pozycję Failover Cluster Manager.
W panelu po lewej stronie, w Menedżerze klastra failover, wybierz klaster, który chcesz skonfigurować.
W panelu po prawej stronie, w obszarze Akcje , wybierz pozycję Więcej akcji, a następnie wybierz pozycję Konfiguruj ustawienia kworum klastra.
W Kreatorze konfigurowania kworum klastra wybierz opcję Dalej.
W sekcji Wybierz opcję konfiguracji kworum, wybierz wybór świadka kworum, a następnie kliknij Dalej.
W obszarze Wybierz obserwator kworum, wybierz Skonfiguruj obserwator w chmurze plików, a następnie Dalej.
W obszarze Skonfigurujświadka chmury wprowadź następujące informacje, a następnie wybierz pozycję Dalej:
Nazwa konta usługi Azure Storage.
Klucz dostępu skojarzony z kontem magazynowym.
Jeśli po raz pierwszy tworzysz świadka w chmurze, użyj podstawowego klucza dostępu.
Jeśli obracasz podstawowy klucz dostępu, zamiast tego użyj pomocniczego klucza dostępu.
Notatka
Zamiast bezpośrednio przechowywać klucze dostępu, klaster awaryjny generuje token sygnatury dostępu współdzielonego (SAS) do bezpiecznego przechowywania. Token pozostaje prawidłowy tylko tak długo, jak skojarzony klucz dostępu jest prawidłowy. Podczas obracania podstawowego klucza dostępu zaktualizuj świadków chmury we wszystkich klastrach korzystających z tego konta magazynu przy użyciu klucza pomocniczego przed ponownym wygenerowaniem klucza podstawowego.
Punkt końcowy usługi platformy Azure
Możesz wprowadzić nazwę innego istniejącego serwera w polu punkt końcowy usługi Azure, jeśli planujesz użyć innego punktu końcowego usługi Azure dla świadka w chmurze, jak na przykład Azure Chiny.
W obszarze Potwierdzeniesprawdź ustawienia kworum, a następnie wybierz Dalej.
W obszarze Podsumowanieprzejrzyj konfigurację świadka, następnie wybierz pozycję Zakończ.
Aby uzyskać więcej szczegółów konfiguracji, możesz wybrać Wyświetl raport.
Po utworzeniu Świadka w chmurze, przejdź do środkowego okienka Menedżera klastra trybu failover, gdzie będzie widoczny w obszarze Zasoby podstawowe klastra.
Zagadnienia dotyczące serwera proxy z Świadkiem w chmurze
Monitor w chmurze używa protokołu HTTPS (domyślny port 443) do nawiązywania komunikacji wychodzącej z usługą Azure Blob. Platforma Azure używa .core.windows.net jako punktu końcowego. Należy upewnić się, że ten punkt końcowy jest uwzględniony w dowolnych listach dozwolonych zapory używanych między klastrem a usługą Azure Storage. Jeśli serwer proxy jest wymagany do nawiązania połączenia z usługą Azure Storage, skonfiguruj usługi HTTP systemu Windows (WinHTTP) przy użyciu wymaganych ustawień serwera proxy. Klaster trybu failover korzysta z protokołu WinHTTP na potrzeby komunikacji HTTPS.
Aby skonfigurować domyślny serwer proxy, możesz użyć polecenia netsh, otwierając okno programu PowerShell z podwyższonym poziomem uprawnień i uruchamiając następujące polecenie:
Notatka
Uruchomienie tego polecenia powoduje zmianę domyślnej konfiguracji serwera proxy dla winHTTP. Może to mieć wpływ na dowolną aplikację, w tym usługi systemu Windows korzystające z winHTTP.
netsh winhttp set proxy proxy-server="<ProxyServerName>:<port>" bypass-list="<HostsList>"
Na przykład:
netsh winhttp set proxy proxy-server="192.168.10.80:8080" bypass-list="<local>; *.contoso.com"