Clustering

Informacja

This feature is currently a technical preview with the following temporary limitation:

• Active/passive setup to support two-node clusters, either by utilizing etcd Learner or Mirror, is not yet available. Use a Witness node instead.

• Nie zostało to jeszcze sprawdzone w wystarczającej liczbie wdrożeń produkcyjnych i mogą występować błędy.

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 **** .

W klastrze, w którym wartość spadnie poniżej tego progu (np. z powodu problemu sieciowego), nie można wybrać lidera, a lokalna instancja serwisu etcd na każdym węźle traci możliwość wykonywania operacji odczytu i zapisu. 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.

If the failed node is still healthy (e.g. it was just a network problem), it will be in the Failed state while isolated, refusing normal operations (not even read-only).

However if the node recovers, it will cleanly resynchronize with the rest of the cluster and exit the Failed state, resuming normal operation without losing data.

Jeśli urządzenie nigdy nie odzyska sprawności, należy je usunąć ` <clustering.html#removing-a-node-cleanly>` __ z klastra i albo poddać je procedurze przywracania sprawności ` <clustering.html#recovering-a-failed-node>` __ w celu uzyskania dostępu do danych (ale nie będzie ono już częścią klastra), albo przywrócić ustawienia fabryczne i ponownie przeprowadzić proces dołączania od początku.

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ą.

• The 2 nodes in location B are not meeting the quorum (still 3), so they will enter the Failed state and stop operating (even read-only).

• Jeśli problem z siecią zostanie rozwiązany, 2 węzły dołączą z powrotem do 3 pozostałych.

Innymi słowy, w najgorszym przypadku rozdzielenie sieci (w klastrze o nieparzystej liczbie węzłów) spowoduje, że większa połowa klastra będzie działać prawidłowo, a mniejsza połowa nie będzie działać do czasu usunięcia rozdzielenia.

Kworum zostało trwale utracone

A failure causing all subsets of the cluster to lose quorum will render the cluster completely inoperable (all remaining nodes will be in the Failed state), unless the failure is resolved. In this case, manual recovery must be performed.

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

The nature of clustering with etcd makes it more reliable the more nodes there are in the cluster. As explained in the Operational Redundancy section, clusters should ideally have at least 3 nodes to have room to fail, since a 2-node cluster will entirely fail if only one fails.

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:

• Write garbage as the value for any entry in the store, which will cause nodes to fail decrypting it (which may lead to crashes for some system entries).

• List entry names such as users, namespaces and keys, which you may consider sensitive.

Co jest współdzielone między węzłami

Posiadanie klastra NetHSM oznacza, że większość danych jest współdzielona między nimi. Każde dodanie, modyfikacja lub usunięcie kluczy, użytkowników lub przestrzeni nazw w jednym węźle jest ostatecznie odzwierciedlane we wszystkich pozostałych. Ogólnie rzecz biorąc, każda operacja modyfikująca stan modyfikuje stan każdego węzła. Obejmuje to operację tworzenia kopii zapasowej restore, która działa normalnie.

Poniższe sekcje szczegółowo opisują, jakie dane są w pełni lokalne, jakie dane są przechowywane we współdzielonym magazynie etcd, ale pozostają specyficzne dla węzła, a jakie dane są w pełni współdzielone między węzłami.

Nie przechowywane w etcd

Klucz urządzenia **** każdego węzła jest przechowywany tylko lokalnie i nigdy nie jest udostępniany między węzłami.

Przechowywane w etcd, ale specyficzne dla węzła

Następujące dane są przechowywane w etcd w różnych zakresach dla każdego węzła. Jest więc dostępny dla każdego węzła, ale nie jednolity między węzłami (każdy węzeł może mieć inną wartość dla tych danych).

Configuration:

• TLS certificates

• Clock configuration

• Konfiguracja sieci

• Logging configuration

• Unattended boot configuration

• Unlock salt (so each node has its own unlock passphrase)

• Locked domain key

Należy pamiętać, że chociaż każdy węzeł ma własną wersję zablokowanego klucza domeny (ponieważ każdy węzeł blokuje go za pomocą własnego klucza urządzenia lub hasła odblokowującego), klucz domeny jest współdzielony między węzłami (aby uzyskać dostęp do ich współdzielonych danych HSM, takich jak klucze).

Przechowywane w etcd i udostępniane

Wszystkie poniższe dane są przechowywane w etcd w zakresie globalnym, więc są jednolite we wszystkich węzłach klastra:

Dane HSM:

• Keys

• Użytkownicy

• Przestrzenie nazw

Configuration:

• Config/domain store version

• Cluster CA (used to authenticate nodes across cluster)

• Backup passphrase and backup salt

Note that for now the config/domain store version can only be version 1 (if your software version supports clustering, then that is what you have). Refer to the Software Updates in Clusters section for more details on the safety of installing software updates within a cluster.

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 as described in the section Network.

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.

W tym celu należy najpierw wygenerować żądanie podpisania certyfikatu (CSR) z węzła, zgodnie z opisem w sekcji TLS Certificate. W przypadku nitropia odbywa się to za pomocą nitropy nethsm --host $NETHSM_HOST csr --api.

Informacja

To properly authenticate nodes, the clustering backend (etcd) expects that each node has a certificate with a properly filled Subject Alt Names (SAN) field. Nodes are expected to be reached only via their IP and need to have a proper IP SAN in their certificate. IP SANs can be requested for the CSR by prefixing „IP:” to the names, as in openssl:

"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]

W przypadku nitropy należy użyć opcji --san, np. --san "IP:192.168.1.1".

Jeśli chcesz korzystać z publicznego urzędu certyfikacji do podpisywania certyfikatów, Twoje węzły muszą używać publicznych adresów IP. Wynika to z wymogu bezpieczeństwa, który zabrania publicznemu urzędowi certyfikacji wydawania certyfikatów zawierających prywatny adres IP w polu IP SAN.

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

new_cert.pem ` <administration.html#tls-certificate>` ** nitropy nethsm –host $NETHSM_HOST set-certificate –api new_cert.pem

Finally, the CA (CA.pem) can now be installed. This is only possible once the installed TLS certificate is signed by it. Otherwise, the operation will be rejected.

nitropyREST API

Argumenty

Argument	Opis
FILENAME	The path of the CA file

Przykład

$ nitropy nethsm --host $NETHSM_HOST set-cluster-ca-certificate CA.pem

Zainstalowany certyfikat CA klastra można sprawdzić za pomocą polecenia ` `` nitropy nethsm –host $NETHSM_HOST get-cluster-ca-certificate`.

Informacja

Proces ten należy powtórzyć dla każdego węzła.

Synchronizacja zegara

Należy upewnić się, że na każdym węźle ustawiono prawidłowy czas systemowy, najlepiej za pomocą protokołu NTP/NTS, a nie poprzez ręczną zmianę ustawień czasu. Można to zrobić poprzez konfigurację Czas oraz NTS/NTP.

Adding a New Node

Adding a node to a cluster is done in three steps:

1. Register the addition to the cluster (through any one of its members)

2. Tell the new node to join

3. Gdy już nadrobi zaległości, należy podnieść status węzła z „uczniowskiego” do pełnoprawnego członka

Configure a Backup Passphrase

First make sure a backup passphrase is configured on the node that will be used to register a new joiner as described in the section Backup.

Rejestrowanie nowego węzła

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.

You can double-check the URL is correct by listing the cluster members on the node that is expected to join. This should list just one member: itself.

nitropyREST API

Przykład

$ nitropy nethsm --host $NETHSM_HOST list-cluster-members

Then register that expected URL on any existing node of the cluster (if you don’t have a cluster yet, do this on the NetHSM that will serve as the initial node of the cluster).

nitropyREST API

Opcje dodatkowe.

Opcja	Opis
--url TEXT	Adres URL węzła równorzędnego nowego węzła (można go ustawić wielokrotnie)

Argumenty

Argument	Opis
JOIN_DATA_PATH	Ścieżka do pliku, do którego zapisywane są dane po połączeniu

Przykład

$ nitropy nethsm --host $NETHSM_HOST add-cluster-member --url https://192.168.1.1:2380 join-data.json

Polecenie to wyświetla listę członków klastra i zapisuje w pliku dane niezbędne nowemu węzłowi do dołączenia do klastra (w tym zestaw do dołączenia). Zachowaj ten plik do wykorzystania w kolejnym kroku.

Informacja

Notice in the list of members (learner: True in the nitropy output, "learner": true in the REST API response) that the new joiner is a „learner”: it can now connect to the cluster and receive data from it, but cannot participate until it is promoted, which will be covered below.

Chociaż ta koncepcja „węzła uczącego się” wprowadza dodatkowy etap (awans), pozwala ona na bezpieczniejsze działanie klastra, ponieważ żadna usterka nowego węzła nie może spowodować niestabilności całego klastra przed jego awansem.

Zachowaj plik z danymi połączenia na potrzeby kolejnego kroku (lub odpowiedź, jeśli korzystałeś z interfejsu API REST).

Joining the Cluster as a Learner

Dołącz do klastra na węźle, który ma zostać do niego dołączony, korzystając z danych z poprzedniego kroku oraz zapasowego hasła węzła, na którym zarejestrowano nowy węzeł.

nitropyREST API

Wymagane opcje.

Opcja	Opis
--backup-passphrase TEXT	Hasło zapasowe węzła, na którym zarejestrowano nowego użytkownika

Argumenty

Argument	Opis
JOIN_DATA_PATH	Ścieżka do pliku danych połączenia z poprzedniego kroku

Przykład

$ nitropy nethsm --host $NETHSM_HOST join-cluster --backup-passphrase $BACKUP_PASSPHRASE join-data.json

Ostrzeżenie

The join call (nitropy nethsm join-cluster or POST /cluster/join) will hang until the new node is manually promoted (see below). This is normal. When the call returns successfully, it indicates that join and promotion have been successful. Don’t cancel this join call.

Assuming both the cluster and the node can reach each other, this will enact the actual join, wiping the data on the new joiner to instead synchronize its state with that of the cluster. If this operation fails immediately (e.g. the cluster was not reachable or authentication failed), this node’s state will not be wiped and the join will be reverted. However as soon as a first join is successful, this operation is final and can only be reverted by a factory reset.

Na tym etapie nowy węzeł dołączył jako węzeł uczący się typu „ ”: synchronizuje się on z klastrem, ale nie jest jeszcze gotowy do pracy. Z drugiej strony, ewentualne problemy z tym węzłem na tym etapie nie spowodują zakłóceń w działaniu klastra, co sprawia, że operacja ta jest bezpieczna.

Ostatnim krokiem niezbędnym do zakończenia procesu dołączenia jest nadanie nowemu węzłowi statusu pełnoprawnego członka.

Promoting the New Learner

W zależności od warunków sieciowych i konfiguracji klastra, zsynchronizowanie się nowego członka z klastrem może zająć trochę czasu. Gdy proces ten dobiegnie końca, można nadać mu status pełnoprawnego członka zamiast statusu członka uczącego się.

Ostrzeżenie

Promoting a node increases the cluster’s quorum threshold (refer to the API documentation and the Operational Redundancy section of this document). Ensure this new node has a stable connection to the cluster before promoting it.

Możesz spróbować awansować nowego członka w następujący sposób. Identyfikator członka można znaleźć, wyświetlając listę członków klastra.

nitropyREST API

Argumenty

Argument	Opis
MEMBER_ID	The ID of the learner to be promoted

Przykład

$ nitropy nethsm --host $NETHSM_HOST promote-cluster-member $MEMBER_ID

Jeśli uczący się nie nadrobił jeszcze zaległości, operacja zakończy się niepowodzeniem (kod HTTP 412 w interfejsie API REST) i należy ponowić próbę awansu w późniejszym terminie.

If this promotion is successful, the node will now have fully joined the cluster and the earlier call to /cluster/join will have returned. The node ends up in a Locked state and has to be unlocked with the unlock passphrase of the node that was used for registration. Afterwards the unlock passphrase can be changed (unlock passphrases remain node-specific and are not shared across nodes).

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.

Transfer to the machine the CA certificate that is being used to authenticate nodes in the cluster. You should have created one in the Creating and Installing a CA section. We’ll store it in /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

Follow the normal instructions from the Registering a New Node section to signal the existing cluster the addition of a new member with the given URL(s).

Keep the join data file written by nitropy nethsm add-cluster-member (or the response from the cluster, if you used the REST API): it contains the list of cluster members and a joiner kit (you won’t need this part).

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,..."

Assuming the join data file written by nitropy (or the NetHSM REST API response) is stored in a response.json file, you can generate these last two variables automatically with the following jq expressions:

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)

For example with the example response provided in the Registering a New Node section, you will have:

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łączyć do klastra jako uczestnik w fazie nauki i nadrobić zaległości w danych.

Promote the Witness

Na koniec, po upływie pewnego czasu, postępuj zgodnie ze standardowymi instrukcjami zawartymi w sekcji „ ” („Przeniesienie nowego ucznia”), aby przenieść świadka. Jeśli to się nie uda, spróbuj ponownie później.

After a successful promotion, you should be able to check that it is healthy with the etcdctl client:

etcdctl get /config/version

Ten klucz powinien istnieć i zawierać „1”.

Make sure this process keeps running, as it is now a proper member of your cluster. If you need to decommission it, first properly remove it from the cluster. If its reachable IP changes, update its URL from the cluster.

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.

You first have to know the ID of the node you want to remove, by listing all nodes and looking for the right one. Then it can be removed. If the node in question was still healthy, this will isolate it from the rest of the cluster and transition it to the Failed state.

nitropyREST API

Argumenty

Argument	Opis
MEMBER_ID	The ID of the node to be removed

Przykład

$ nitropy nethsm --host $NETHSM_HOST remove-cluster-member $MEMBER_ID

Informacja

Węzeł, który dołączył do klastra, ale nie został jeszcze awansowany, można również w ten sposób bezpiecznie usunąć.

Recovering a Failed Node

Węzeł zgłaszający stan „ Failed” ( nie powiodło się) nie będzie odpowiadał na większość standardowych operacji. Nadal można go jednak wyłączyć, zrestartować, zresetować , zdiagnozować lub oraz odizolować.

Ostrzeżenie

Istnienie operacji „ ” (Błąd „ ”), „ ` ” (diagnose`) oraz „ ` ” (force-new`) dotyczy wyłącznie wersji 5.0 i nowszych. W wersji 4.0 węzeł, który utracił kworum, przestaje odpowiadać na wszystkie żądania typu „ ” ( ). Należy go przywrócić do ustawień fabrycznych ( ) ( ).

Do typowych przyczyn, dla których węzeł może znajdować się w stanie „ ” (Niepowodzenie), należą:

• Trwale utracony kworum.

• Czasowa utrata kworum (np. podczas dodawania drugiego węzła do klastra, gdy węzeł ten nie dołączył jeszcze do klastra).

• Serwer `etcd` jest obecnie uruchamiany ponownie (np. z powodu zmiany certyfikatów lub ponownej konfiguracji sieci).

• Klaster jest poddawany bardzo dużemu obciążeniu (np. podczas przywracania bardzo dużej kopii zapasowej).

Niezależnie od przyczyny, urządzenie NetHSM przejdzie do stanu „ ” (Błąd komunikacji z serwerem) dopiero po upływie co najmniej jednej pełnej minuty nieudanych prób nawiązania połączenia z bazą danych. Ma to na celu uniknięcie fałszywych przejść spowodowanych bardzo krótkotrwałymi zaburzeniami.

To help you understand which case your node is in, the diagnose function remains available and returns information about the current status of etcd and its database, including logs.

nitropyREST API

Przykład

$ nitropy nethsm --host $NETHSM_HOST get-cluster-diagnostics

Informacja

Gdy baza danych znów stanie się dostępna (np. po przywróceniu kworum w wyniku rozwiązania problemu sieciowego), moduł NetHSM automatycznie przejdzie ze stanu „ Failed” ( ) do stanu, w którym znajdował się wcześniej (lub wznowi normalną sekwencję uruchamiania, jeśli był w trakcie uruchamiania), bez konieczności podejmowania jakichkolwiek ręcznych działań. Stabilizacja klastra, wykrycie przez HSM, że problem został rozwiązany, oraz zmiana stanu potrwają do jednej minuty od momentu usunięcia problemu.

Jeśli uznasz, że awaria ma charakter trwały (np. utrata kworum bez szans na rozwiązanie przyczyny leżącej u jej podstaw), możesz:

• Przywróć ustawienia fabryczne węzła, co spowoduje usunięcie wszystkich danych, a następnie przywróć kopię zapasową.

• Isolate the node with nitropy nethsm force-new-cluster (REST API: POST /cluster/force-new), which will irreversibly forget all other cluster members, recover the etcd data present on disk and reboot. If the underlying failure was cluster-related, the node will follow the normal boot sequence and end up in either the Locked or Operational state depending on the unattended boot setting.

Informacja

If a node is isolated with force-new, it will desynchronized with the cluster: any new writes on it or the cluster cannot be reconciled. The node can still rejoin the cluster but will lose all its local modifications.

The force-new operation, which is only available in the Failed state, requires authentication as it is potentially destructive. However since HSM users and roles are not available in that state, the endpoint expects HTTPS clients to always authenticate with the unlock fake user, and the latest known unlock passphrase as the password. With nitropy, pass them as --username unlock --password $UNLOCK_PASSPHRASE:

$ nitropy nethsm --host $NETHSM_HOST --username unlock --password $UNLOCK_PASSPHRASE force-new-cluster

Ostrzeżenie

Po aktualizacji z wersji niższej niż 5.0 punkt końcowy force-new będzie zawsze zwracał komunikat „Unauthorized”, dopóki moduł HSM nie zostanie odblokowany lub hasło odblokowujące nie zostanie zmienione co najmniej raz.

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.