Clustering¶
Informacja
Ta funkcja jest obecnie techniczną wersją zapoznawczą z następującymi tymczasowymi ograniczeniami:
Jeśli klaster zostanie utracony (kworum zostanie utracone), jedynym sposobem na odzyskanie jest fabryczny reset + przywracanie. Należy często tworzyć kopie zapasowe. Przyszłe wersje będą zawierać środki do odzyskiwania danych z dysku.
Aktywna/pasywna konfiguracja do obsługi klastrów z dwoma węzłami, wykorzystująca etcd Learner lub Mirror, nie jest jeszcze dostępna.
Czas systemowy między węzłami musi być obecnie synchronizowany ręcznie. Przyszła wersja będzie zawierać automatyczną synchronizację zegara.
NetHSM od wersji 4.0 obsługuje klastrowanie w celu bezpośredniej synchronizacji danych między kilkoma NetHSM. Zapewnia to wysoką częstotliwość generowania kluczy, wysoką dostępność i równoważenie obciążenia. Klaster NetHSM jest oparty na etcd, który wykorzystuje algorytm konsensusu Raft dla zapewnienia silnej spójności. Gwarantuje to, że dane (np. klucze) są poprawne we wszystkich NetHSM przez cały czas.
Przed skonfigurowaniem klastra NetHSM należy zapoznać się z tą technologią i jej ograniczeniami, aby uniknąć przypadkowej awarii i utraty danych. Oprócz tego dokumentu warto również zapoznać się z dokumentacją etcd.
Operational Redundancy¶
Będziemy nazywać „węzłem” NetHSM, który ma być częścią klastra. Klaster węzłów N będzie działał tak długo, jak długo co najmniej węzły (N/2)+1 będą zdrowe i osiągalne. Ta minimalna liczba zdrowych, osiągalnych węzłów nazywana jest kworum **** .
Oznacza to następujące scenariusze.
Jeden węzeł ulega awarii, a kworum jest nadal osiągane¶
W 3-węzłowym klastrze, jeśli jeden węzeł ulegnie awarii (ulegnie awarii lub stanie się nieosiągalny z powodu warunków sieciowych), dwa pozostałe węzły będą nadal działać i obsługiwać żądania.
Jeśli uszkodzony węzeł jest nadal zdrowy (np. był to tylko problem z siecią), nie będzie działał podczas izolacji (nawet tylko do odczytu).
Jeśli jednak węzeł odzyska sprawność, zostanie zsynchronizowany z resztą klastra i ponownie zacznie działać bez utraty danych.
Jeśli nigdy nie odzyska sprawności, musi zostać usunięty z klastra (patrz następna sekcja), przywrócony do ustawień fabrycznych i ponownie przejść przez proces dołączania od zera.
Następuje podział sieci, a kworum jest nadal osiągane¶
Jest to tylko uogólnienie poprzedniego scenariusza. W 5-węzłowym klastrze, w którym np. 3 węzły znajdują się w jednej fizycznej lokalizacji A, a 2 węzły w innej lokalizacji B, problem sieciowy izolujący A i B oznaczałby, co następuje:
3 węzły w lokalizacji A spełniają kworum (w tym przypadku 3), więc nadal działają.
2 węzły w lokalizacji B nie **** spełniają kworum (nadal 3), więc przestaną działać (nawet tylko do odczytu).
Jeśli problem z siecią zostanie rozwiązany, 2 węzły dołączą z powrotem do 3 pozostałych.
Kworum zostało trwale utracone¶
Awaria powodująca utratę kworum przez wszystkie podzbiory klastra spowoduje całkowitą utratę klastra i jego danych, chyba że awaria zostanie usunięta. W takim przypadku należy zresetować węzły i przywrócić kopię zapasową.
Może się to zdarzyć na przykład w przypadku awarii pojedynczego węzła w klastrze 2-węzłowym (gdzie kworum wynosi 2). W takiej sytuacji uszkodzony węzeł nie może zostać czysto usunięty z klastra po fakcie, ponieważ pozostały zdrowy węzeł już nie działa, ponieważ utracił kworum.
Dlatego zaleca się, aby zawsze mieć nieparzystą liczbę węzłów w klastrze i często tworzyć kopie zapasowe.
Dla jasności, tymczasowo utrata kworum (na przykład w przypadku ponownego uruchomienia wszystkich węzłów klastra razem lub tymczasowej awarii sieci izolującej węzły) nie stanowi problemu: po ponownym połączeniu wystarczającej liczby węzłów (bez konieczności ręcznego ponownego łączenia) w celu osiągnięcia kworum, klaster wznowi normalne działanie. Tylko trwałe awarie, takie jak partycje sieciowe, błędna konfiguracja sieci, problemy z uwierzytelnianiem lub awarie sprzętu, będą wymagały ręcznego działania.
Więcej informacji można znaleźć w FAQ etcd.
Klaster 2-węzłowy¶
Dwuwęzłowy aktywny/pasywny klaster nie jest jeszcze obsługiwany i zostanie dodany w przyszłej wersji. Zalecamy wprowadzenie trzeciego węzła, albo trzeciego NetHSM, albo „świadka” etcd, który może być obsługiwany na dowolnym hoście. Zobacz następną sekcję „Świadek”.
Świadek¶
Natura klastrowania z etcd sprawia, że jest ono tym bardziej niezawodne, im więcej węzłów znajduje się w klastrze. Jak wyjaśniono w sekcji Operational Redundancy, klastry powinny mieć co najmniej 3 węzły, aby mieć miejsce na awarię, ponieważ 2-węzłowy klaster całkowicie zawiedzie, jeśli zawiedzie tylko jeden.
Konstrukcja funkcji jest jednak taka, że nie trzeba dodawać pełnego, rzeczywistego urządzenia NetHSM do klastra, aby osiągnąć stabilną liczbę węzłów. Zamiast tego można samodzielnie wdrożyć i dodać węzeł „świadek”. Taki węzeł to po prostu instancja etcd uruchomiona na wybranej maszynie (lub w kontenerze) i podłączona do klastra. Zostanie on rozpoznany jako normalny węzeł z prawdziwych urządzeń w klastrze i otrzyma wszystkie dane i aktualizacje z urządzeń (ale oczywiście nie będzie można wykonywać na nim żadnych operacji HSM - przechowuje on tylko dane).
Security Considerations¶
Węzeł świadek (lub każdy, kto ma do niego dostęp) ma bezpośredni dostęp do zaplecza pamięci masowej wszystkich węzłów w klastrze (np. można zrzucić wszystkie wpisy i odpowiadające im wartości za pomocą etcdctl get "/" "0").
Jednak z wyjątkiem wersji konfiguracji (/config/version, która zawsze powinna wynosić „1”), ściśle wszystkie wartości są szyfrowane (kluczem urządzenia dla wartości specyficznych dla węzła lub kluczami domeny dla innych), zapewniając poufność wrażliwych danych.
Należy jednak pamiętać, że złośliwy węzeł może:
zapisać śmieci jako wartość dowolnego wpisu w magazynie, co spowoduje, że węzły nie będą mogły go odszyfrować (co może prowadzić do awarii niektórych wpisów systemowych).
lista nazw wpisów, takich jak użytkownicy, przestrzenie nazw i klucze, które można uznać za wrażliwe.
Creating a Cluster¶
Każdy klaster będzie początkowo składał się z jednego węzła. Nowe węzły będą dołączać do klastra jeden po drugim.
Preparing Nodes¶
Ruch sieciowy między węzłami jest szyfrowany i uwierzytelniany przy użyciu ich certyfikatu TLS.
Wszystkie węzły, które mają być częścią tego samego klastra, muszą najpierw zainstalować wspólny urząd certyfikacji (CA), który pozwoli im zweryfikować, czy inne węzły są legalne.
W dalszej części zakładamy, że wszystkie węzły są świeżo udostępnione i działają.
Networking¶
Nodes must first be reconfigured with their expected final network configuration using the /config/network endpoint (refer to the API documentation).
Tworzenie i instalacja urzędu certyfikacji¶
Użytkownicy powinni utworzyć urząd certyfikacji za pomocą własnych środków i zgodnie z własnymi ograniczeniami operacyjnymi, upewniając się, że pozwala on co najmniej na użycie klucza keyCertSign.
Na przykład, minimalny urząd certyfikacji można utworzyć za pomocą openssl:
$ openssl genrsa -out CA.key 2048 # create a key
$ openssl req -x509 -new -nodes -key CA.key -sha256 -days 1825 -out CA.pem -addext keyUsage=critical,keyCertSign
Ten urząd certyfikacji musi być teraz zainstalowany na każdym węźle.
To do this, first generate a Certificate Signing Request (CSR) from the node with the /config/tls/csr.pem endpoint (refer to the API documentation).
Informacja
Aby prawidłowo uwierzytelnić węzły, zaplecze klastrowania (etcd) oczekuje, że każdy węzeł ma certyfikat z prawidłowo wypełnionym polem Subject Alt Names (SAN). W szczególności węzły, które mają być osiągalne tylko za pośrednictwem ich adresu IP, muszą mieć odpowiednią sieć SAN IP w swoim certyfikacie. Sieci SAN IP mogą być wymagane dla CSR poprzez dodanie prefiksu „IP:” do nazw, jak w openssl:
"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]
Biorąc pod uwagę uzyskany CSR (nazwijmy go nethsm.csr), możemy następnie wygenerować dla niego certyfikat, gotowy do zainstalowania. Na przykład z openssl:
$ openssl x509 -req -days 1825 -in nethsm.csr -CA CA.pem -copy_extensions copy \
-CAkey CA.key -out new_cert.pem -set_serial 01 -sha256
Then install the obtained new_cert.pem with the /config/tls/cert.pem endpoint (refer to the API documentation).
Wreszcie, CA (CA.pem) można teraz zainstalować za pomocą punktu końcowego /config/tls/cluster-ca.pem (patrz dokumentacja API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Jest to możliwe tylko wtedy, gdy zainstalowany certyfikat TLS jest przez niego podpisany. W przeciwnym razie operacja zostanie odrzucona.
Informacja
Proces ten należy powtórzyć dla każdego węzła.
Synchronizacja zegara¶
Upewnij się, że każdy węzeł został zaopatrzony w dokładny czas systemowy. Jeśli nie, dostosuj ich zegary za pomocą punktu końcowego /config/time.
Adding a New Node¶
Dodanie węzła do klastra odbywa się w dwóch krokach:
zarejestrować dodatek do klastra (za pośrednictwem dowolnego z jego członków)
nakazuje nowemu węzłowi dołączenie
Configure a Backup Passphrase¶
Najpierw upewnij się, że zapasowe hasło jest skonfigurowane na węźle, który zostanie użyty do zarejestrowania nowego łącznika (zobacz dokumentację API punktu końcowego /config/backup-passphrase).
Rejestrowanie nowego węzła¶
Ostrzeżenie
Zarejestrowanie węzła natychmiast wprowadza nowy węzeł do klastra, modyfikując próg kworum, nawet jeśli węzeł jeszcze nie dołączył. Może to spowodować, że istniejące węzły nie będą działać do czasu faktycznego dołączenia nowego węzła. Zapoznaj się z dokumentacją API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __ i sekcją Operational Redundancy tego dokumentu.
Należy mieć pod ręką adres IP węzła, który się przyłączy. Pełny adres URL ** (nazywany również peer URL w terminologii etcd) tego węzła będzie https://<IP_of_node>:2380 (np. https://192.168.1.1:2380). Port musi być 2380, więc upewnij się, że firewall między węzłami zezwala na ruch TCP na tym porcie.
Możesz dwukrotnie sprawdzić, czy adres URL jest poprawny, wywołując GET /cluster/members na węźle, który ma zostać dołączony. Powinno to wyświetlić tylko jednego członka: samego siebie.
Następnie zarejestruj ten oczekiwany adres URL na dowolnym istniejącym węźle klastra (jeśli nie masz jeszcze klastra, zrób to na NetHSM, który posłuży jako początkowy węzeł klastra). Odbywa się to za pomocą punktu końcowego POST /cluster/members (patrz dokumentacja API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __), przekazując mu treść JSON zawierającą adres URL.
Jeśli się powiedzie, zwraca treść formularza w formacie JSON:
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
]
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
]
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
który zawiera informacje niezbędne do dołączenia nowego węzła do klastra. W szczególności zawiera listę wszystkich członków klastra (gdzie członek z pustą nazwą jest nowym członkiem). Zawiera również klucz domeny zaszyfrowany zarówno przez hasło odblokowujące, jak i zapasowe - więc hasło zapasowe musiało zostać skonfigurowane wcześniej.
Zachowaj tę odpowiedź do następnego kroku.
Rzeczywiste dołączenie do klastra¶
Weź odpowiedź z ostatniego kroku i dołącz do niej pole backupPassphrase zawierające zapasowe hasło węzła, na którym zarejestrowano nowego dołączającego, i przekaż te dane do wywołania POST /cluster/join (patrz dokumentacja API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __) na węźle, który ma dołączyć.
Zakładając, że zarówno klaster, jak i węzeł mogą się ze sobą skontaktować, spowoduje to faktyczne dołączenie, wymazując dane nowego dołączającego, aby zamiast tego zsynchronizować jego stan ze stanem klastra.
W zależności od warunków sieciowych i klastra operacja ta może potrwać kilkadziesiąt sekund. Jeśli ta operacja nie powiedzie się natychmiast (np. klaster nie był osiągalny lub uwierzytelnianie nie powiodło się), stan tego węzła nie zostanie wyczyszczony, a połączenie zostanie przywrócone. Jednak gdy tylko pierwsze dołączenie zakończy się powodzeniem, operacja ta jest ostateczna i można ją przywrócić tylko poprzez przywrócenie ustawień fabrycznych.
Jeśli to połączenie się powiedzie, węzeł znajdzie się w stanie Locked i musi zostać odblokowany za pomocą hasła odblokowującego węzła, który został użyty do rejestracji. Następnie hasło odblokowujące może zostać zmienione (hasła odblokowujące pozostają specyficzne dla węzła i nie są współdzielone między węzłami).
Informacja
Nawet po pomyślnym dołączeniu, jeśli baza danych klastra jest duża lub klaster jest zajęty, może upłynąć trochę czasu, zanim nowy podmiot dołączający w pełni zsynchronizuje swój stan. W tym czasie wszystkie węzły (w tym w szczególności nowy łącznik) mogą być mniej responsywne lub nie reagować. W szczególności nowy łącznik może początkowo zwracać błędy podczas próby jego odblokowania. W takim przypadku należy dać mu trochę czasu i spróbować ponownie.
Adding a Witness Node¶
Prepare a Witness¶
Potrzebne będzie środowisko z dostępnym etcd v3.6, z adresem IPv4 (co najmniej) osiągalnym przez innych członków klastra. Ruch TCP do i z portu 2380 musi być dozwolony.
Utwórz pusty katalog, w którym etcd będzie przechowywać swoje dane i zapisz jego ścieżkę (użyjemy /var/etcd/data). Upewnij się, że użytkownik, który uruchomi proces, ma uprawnienia do odczytu i zapisu w katalogu.
Przenieś na maszynę certyfikat CA, który jest używany do uwierzytelniania węzłów w klastrze. Powinieneś go utworzyć w sekcji Tworzenie i instalacja CA. Będziemy go przechowywać w /var/etcd/CA.pem.
Następnie należy utworzyć certyfikat dla świadka i podpisać go w urzędzie certyfikacji, aby mógł komunikować się ze swoimi rówieśnikami. Można to zrobić na przykład poprzez openssl:
# Create a key
$ openssl genrsa -out witness.key 2048
# Create a CSR with a SAN that corresponds to the witness's IP or hostname
$ openssl req -new -sha256 -key own.key -subj "/C=US/ST=CA/O=MyOrg, Inc./CN=witness" \
-addext "subjectAltName=IP:172.22.1.3" --out witness.csr
# Sign it
$ openssl x509 -req -days 1825 -in witness.csr -CA CA.pem -copy_extensions copy \
-CAkey CA.key -out witness.pem -set_serial 01 -sha256
Przechowuj również wynikowe witness.key i witness.pem w /var/etcd.
Register Witness to Cluster¶
Postępuj zgodnie z normalnymi instrukcjami z sekcji Registration a New Node, aby zasygnalizować istniejącemu klastrowi dodanie nowego członka z podanym adresem URL.
Zapisz odpowiedź z klastra: powinna ona zawierać listę członków klastra i zestaw dołączający (ta część nie będzie potrzebna).
Configure etcd¶
W przeciwieństwie do NetHSM, które automatycznie wybierają dla siebie nazwę węzła (używając identyfikatora urządzenia), należy wybrać nazwę dla każdego dodawanego świadka, upewniając się, że nazwy są unikalne. W poniższych przykładach użyjemy nazwy „witness1”.
Wraz z odpowiedzią NetHSM na rejestrację świadka należy przygotować zmienne formularza:
export ETCD_NAME="witness1"
export ETCD_DATA_DIR="/var/etcd/data"
export ETCD_INITIAL_CLUSTER="peer1=url1,peer1=url2,peer2=url1,peer2=url2,..."
export ETCD_INITIAL_ADVERTISE_PEER_URLS="my_url1,my_url2,..."
Zakładając, że odpowiedź NetHSM jest przechowywana w pliku response.json, można wygenerować te dwie ostatnie zmienne automatycznie za pomocą następujących wyrażeń jq:
export ETCD_INITIAL_CLUSTER=$(jq --raw-output '[.members[] | ["\(if .name == "" then "witness1" else .name end)=\(.urls[])"]] | flatten | join(",")' < response.json)
export ETCD_INITIAL_ADVERTISE_PEER_URLS=$(jq --raw-output '.members[] | select(.name=="") | .urls | join(",")' < response.json)
Na przykład w przypadku przykładowej odpowiedzi podanej w sekcji Rejestracja nowego węzła, otrzymasz:
ETCD_NAME="witness1"
ETCD_DATA_DIR="/var/etcd/data"
ETCD_INITIAL_CLUSTER="witness1=https://172.22.1.3:2380,9ZVNM2MNWP=https://172.22.1.2:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://172.22.1.3:2380"
Na koniec utwórz plik etcd.conf.yml, używając pliku szablonu dostarczonego w docs/etcd_witness.conf.template:
$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml
Powinno to spowodować wyświetlenie pliku formularza:
name: witness1
data-dir: /var/etcd/data
log-level: warn
log-format: console
listen-peer-urls: https://0.0.0.0:2380
listen-client-urls: http://localhost:2379
initial-advertise-peer-urls: https://172.22.1.3:2380
advertise-client-urls: http://localhost:2379
initial-cluster: witness1=https://172.22.1.3:2380,9ZVNM2MNWP=https://172.22.1.2:2380
initial-cluster-state: 'existing'
peer-transport-security:
cert-file: witness.pem
key-file: witness.key
client-cert-auth: true
trusted-ca-file: CA.pem
skip-client-san-verification: true
Start etcd¶
Uruchom etcd w preferowany sposób (ręcznie, systemd usługa, kontener itp.), wskazując na plik konfiguracyjny utworzony w poprzednim kroku:
$ cd /var/etcd
$ etcd --config-file witness.conf.yml
Powinieneś zobaczyć, jak się uruchamia, dołącza do klastra i dogania dane. Po pewnym czasie powinieneś być w stanie sprawdzić, czy jest zdrowy za pomocą klienta etcdctl:
etcdctl get /config/version
Ten klucz powinien istnieć i zawierać „1”.
Upewnij się, że proces ten jest nadal uruchomiony, ponieważ jest teraz prawidłowym członkiem klastra. Jeśli musisz go zlikwidować, najpierw prawidłowo usuń go z klastra (zobacz dedykowaną sekcję). Jeśli zmieni się jego osiągalny adres IP, zaktualizuj jego adres URL z klastra.
Operating a Cluster¶
Kopia zapasowa i przywracanie¶
Operacja tworzenia kopii zapasowej działa tak samo, jak bez klastra i można jej zażądać z dowolnego węzła klastra. Spowoduje ona utworzenie kopii zapasowej danych dla całego klastra, w tym pól specyficznych dla węzła (choć zostaną one zignorowane, chyba że kopia zapasowa zostanie przywrócona na nieobsługiwanym węźle).
Kopię zapasową wykonaną w klastrze można przywrócić w tym samym klastrze, nawet jeśli od tego czasu niektóre węzły zostały dodane lub usunięte. Takie przywracanie wykonane na klastrach operacyjnych nie wpłynie na wartości konfiguracyjne (tylko klucze, użytkownicy, przestrzenie nazw), jak każde inne częściowe przywracanie.
Przywrócenie kopii zapasowej na nieobsługiwanym węźle spowoduje przywrócenie pól specyficznych dla węzła (takich jak konfiguracja sieci, certyfikaty itp.) węzła, który został użyty do utworzenia kopii zapasowej.
Przywracanie dużej kopii zapasowej może przez pewien czas obciążać klaster, podczas gdy węzeł stosujący przywracanie przekazuje zmiany do innych.
Operacja ta pozostaje kompatybilna z kopiami zapasowymi wykonanymi na poprzednich wersjach NetHSM.
Informacja
Przywrócenie na węźle A kopii zapasowej wykonanej na innym węźle Z z innym kluczem domeny spowoduje poprawne przepisanie klucza domeny A, tak jak poprzednio. Jeśli jednak A znajdował się w klastrze z węzłem B, B przestanie działać, ponieważ klucz domeny Z nie zostanie przywrócony na B.
Innymi słowy, przywracanie należy wykonywać tylko w klastrze z kopiami zapasowymi wykonanymi w tym samym klastrze (choć od tego czasu węzły mogły zostać usunięte lub dodane). Jeśli chcesz przywrócić obcą kopię zapasową na węźle, najpierw bezpiecznie usuń go z klastra, a następnie przywróć ustawienia fabryczne i przywróć kopię zapasową.
Czyste usuwanie węzła¶
Tak długo, jak część klastra nadal spełnia kworum, każdy z jego członków może zostać użyty do usunięcia innego węzła z klastra, niezależnie od tego, czy ten węzeł jest już nieosiągalny, czy też oczekuje się, że będzie.
Najpierw musisz znać identyfikator węzła, który chcesz usunąć, wyświetlając listę wszystkich węzłów za pośrednictwem GET /cluster/members i szukając właściwego.
Następnie można go usunąć, wywołując DELETE /cluster/members/<id>. Jeśli dany węzeł był nadal zdrowy, spowoduje to odizolowanie go od reszty klastra i uniemożliwi jego działanie.
Software Updates in Clusters¶
Przyszłe aktualizacje zostaną oznaczone jako „cluster-safe” (powinna to być większość) lub „cluster-unsafe”.
Aktualizacje bezpieczne dla klastrów mogą być stosowane do węzłów, które są częścią klastra bez wcześniejszego usuwania ich z klastra. Jednak tak jak w przypadku wszystkich operacji, należy upewnić się, że jest to wykonywane na jednym węźle naraz i w klastrze, w którym usunięcie węzła nie spadnie poniżej kworum (np. jeśli aktualizacja się nie powiedzie).
Aktualizacje niebezpieczne dla klastrów muszą być stosowane do odizolowanych węzłów. Należy zdemontować klaster (usuwając węzły jeden po drugim), przywrócić ustawienia fabryczne wszystkich węzłów z wyjątkiem jednego, zastosować aktualizację do każdego węzła, a następnie sprawić, by wszystkie zresetowane węzły dołączyły do pozostałego węzła.
Przed takimi operacjami należy wykonać kopię zapasową.
Rekonfiguracja istniejącego klastra¶
Changing the Cluster CA¶
Istniejący klaster (z dwoma lub więcej węzłami) nie może zmienić swojego urzędu certyfikacji klastra podczas działania. Jeśli musisz zmienić ten certyfikat: wybierz węzeł, usuń wszystkie inne węzły, zaktualizuj urząd certyfikacji, a następnie poproś pozostałych członków o ponowne dołączenie.
Changing the Network Configuration of Nodes¶
Modyfikacja konfiguracji sieciowej węzła (np. zmiana jego adresu IP) automatycznie poinformuje inne węzły o aktualizacji. Powinieneś jednak upewnić się, że wykonujesz takie aktualizacje tylko na jednym węźle naraz i w klastrze, w którym utrata tego węzła nie spowoduje utraty kworum.