Utrzymywanie zestawów replik MongoDB w chmurze za pomocą Ansible

Replikacja znalazła szerokie zastosowanie w systemach bazodanowych w celu zapewnienia wysokiej dostępności danych poprzez tworzenie redundancji. Jest to w zasadzie strategia tworzenia kopii tych samych danych na różnych działających serwerach, które mogą znajdować się na różnych maszynach, tak aby w przypadku awarii głównego serwera można było uruchomić inny serwer.

Zestaw replik to grupa instancji MongoDB, które przechowują ten sam zestaw danych. Stanowią podstawę wdrożeń produkcyjnych. Replikacja jest korzystna ze względu na to, że dane są zawsze dostępne z innego serwera na wypadek awarii systemu serwera głównego. Poza tym poprawia przepustowość odczytu, umożliwiając klientowi wysyłanie żądania odczytu do różnych serwerów i otrzymywanie odpowiedzi od najbliższego.

Zestaw replik składa się z kilku węzłów przenoszących dane, które mogą być hostowane na różnych maszynach oraz węzła arbitra. Jeden z tych węzłów przenoszących dane jest oznaczony jako główny, podczas gdy pozostałe są węzłami drugorzędnymi. Główny węzeł odbiera wszystkie operacje zapisu, a następnie replikuje dane do innych węzłów po zakończeniu operacji zapisu i zarejestrowaniu zmian w oplogu.

Arbiter to dodatkowa instancja, która nie utrzymuje zestawu danych, ale zapewnia kworum w zestawie replik, odpowiadając na prośby o bicie serca i wybory innych członków zestawu replik. W ten sposób zmniejszają koszty utrzymania zestawu replik, a nie w pełni funkcjonalnego członek zestawu replik z zestawem danych.

Automatyczne przełączanie awaryjne

Węzeł główny może ulec awarii z pewnych powodów, takich jak przerwy w dostawie prądu lub rozłączenie sieci, przez co nie będzie w stanie komunikować się z innymi członkami. Jeśli komunikacja zostanie odcięta na dłużej niż skonfigurowany okres czasu choiceTimeoutMillis, jeden z drugorzędnych elementów wezwie do wyboru, aby nominować się jako nowy podstawowy. Jeśli wybory zostaną zakończone i pomyślne, klaster kontynuuje normalne działanie. W tym okresie nie można wykonywać żadnych operacji zapisu. Jednak zapytania odczytu można skonfigurować tak, aby działały normalnie na drugorzędnych, gdy podstawowy jest offline.

Aby proces replikacji był optymalny, mediana czasu, zanim klaster wybierze nową, maksymalną wartość podstawową, powinna wynosić 12 sekund przy domyślnych ustawieniach konfiguracji replikacji. Mogą na to wpływać takie czynniki, jak opóźnienie sieci, które może wydłużyć czas, dlatego należy wziąć pod uwagę architekturę klastra, aby upewnić się, że ten czas nie jest zbyt wysoki.

Wartość choiceTimeoutMillis może być obniżona z domyślnej wartości 10000 (10 sekund), dzięki czemu podstawowa może zostać wykryta jako pierwsza w bardzo szybkim tempie. Jednak może to być częste wywoływanie wyborów nawet z powodu drobnych czynników, takich jak tymczasowe opóźnienie sieci, nawet jeśli węzeł podstawowy jest sprawny. Doprowadzi to do problemów, takich jak wycofywanie operacji zapisu.

Ansible dla zestawów replik

Jak wspomniano, zestaw replik może zawierać elementy z różnych maszyn hostów, co utrudnia utrzymanie klastra. Potrzebujemy jednej platformy, z której można łatwo konserwować ten zestaw replik. Ansible to jedno z narzędzi, które zapewnia lepszy przegląd konfiguracji i zarządzania zestawem replik. Jeśli jesteś nowicjuszem w ansible, zrób krótkie podsumowanie tego artykułu, aby zrozumieć podstawy, takie jak tworzenie podręcznika.

Parametry konfiguracji

arbiter_at_index: definiuje to pozycję arbitra na liście członków zestawu replik. Pamiętaj, że arbiter nie ma żadnych danych jak inni członkowie i nie może być używany jako węzeł główny. Możliwe jest tylko utworzenie kworum podczas wyborów. Na przykład, jeśli masz parzystą liczbę członków, dobrze jest dodać arbitra, aby jeśli głosy były równe, dodaje 1, aby uzyskać zwycięskiego członka. Wartość do przypisania powinna być liczbą całkowitą.
chaining_allowed: Pobiera to wartość logiczną i określa, czy inne drugorzędne elementy członkowskie powinny być replikowane z innych drugorzędnych elementów członkowskich, jeśli łączenie w łańcuch _allowed =true. W przeciwnym razie, jeśli łańcuch _allowed =false, inne pomocnicze elementy członkowskie mogą replikować tylko z podstawowego. Domyślna wartość to prawda.
election_timeout_secs: domyślna wartość to 10000 (przyjmuje wartość całkowitą). Jest to czas w milisekundach na wykrycie, kiedy węzeł podstawowy jest nieosiągalny lub raczej nie komunikuje się z innymi członkami, a tym samym wyzwala wybór. Ustaw to na średnią wartość 12 sekund. Jeśli jest ustawiony zbyt wysoko, wykrycie pierwotnej awarii zajmie dużo czasu, a co za tym idzie, wykonanie elekcji. Ponieważ wpływa to na operację zapisu, w tym okresie możesz stracić dużo danych. Z drugiej strony, jeśli jest ustawiony zbyt nisko, będzie często uruchamiać wybory, nawet jeśli sprawa nie jest tak poważna, a podstawowa nadal jest osiągalna. W rezultacie będziesz mieć tak wiele cofnięć operacji zapisu, które w pewnym momencie mogą prowadzić do słabej integralności lub niespójności danych.
heartbeat_timeout_secs: Zestawy replik muszą komunikować się ze sobą przed wyborami, wysyłając sygnał zwany biciem serca. Członkowie muszą następnie odpowiedzieć na tę sygnalizację w określonym czasie, który domyślnie jest ustawiony na 10 sekund. Heartbeat_timeout_secs to liczba sekund, przez którą członkowie zestawu replik czekają na pomyślne bicie serca od siebie, a jeśli członek nie odpowiada, jest oznaczany jako niedostępny. Ma to jednak zastosowanie tylko do protokołu w wersji 0. Wartość ta jest zatem liczbą całkowitą.
login_host: To jest host, na którym znajduje się baza danych logowania. Domyślnie dla MongoDB jest host lokalny.
baza_danych_logowania: domyślnym jest administrator i jest to miejsce, w którym przechowywane są dane logowania. (przyjmuje wartość ciągu)
login_user: nazwa użytkownika, za pomocą której należy przeprowadzić uwierzytelnianie. (przyjmuje wartość ciągu)
login_password: hasło do uwierzytelnienia użytkownika. (przyjmuje wartość ciągu)
port_logowania: Jest to port MongoDB, do którego host ma się logować. (przyjmuje wartość całkowitą)
członkowie: definiuje listę członków zestawu replik. Jest to ciąg znaków oddzielony przecinkiem lub listą yaml, np. mongodb0:27017,mongodb2:27018,mongodb3:27019… Jeśli nie ma numeru portu, przyjmuje się 27017.
wersja_protokołu: przyjmuje liczbę całkowitą, która definiuje wersję procesu replikacji. 0 lub 1
zestaw_replik: jest to wartość ciągu, która definiuje nazwę zestawu replik.
SSL: wartość logiczna, która określa, czy używać połączenia SSL podczas łączenia się z bazą danych, czy nie.
ssl_certs_reqs: określa to, czy wymagany jest certyfikat po drugiej stronie połączenia i czy będzie trzeba go zweryfikować, jeśli zostanie dostarczony. Dostępne opcje to CERT_NONE, CERT_OPTIONAL i CERT_REQUIRED. Wartość domyślna to CERT_REQUIRED.
zatwierdź: przyjmuje wartość logiczną, która określa, czy wykonać podstawową walidację podanej konfiguracji zestawu replik. Domyślna wartość to prawda.

Tworzenie zestawu replik MongoDB za pomocą Ansible

Oto prosty przykład zadań związanych z konfiguracją zestawu replik w ansibie. Nazwijmy ten plik zadaniami.yaml

# Create a replicaset called 'replica0' with the 3 provided members
- name: Ensure replicaset replica0 exists
  mongodb_replicaset:
    login_host: localhost
    login_user: admin
    login_password: root
    replica_set: replica0
    arbiter_at_index:2
    election_timeout_secs:12000
    members:
    - mongodb1:27017
    - mongodb2:27018
    - mongodb3:27019
  when: groups.mongod.index(inventory_hostname) == 0

# Create two single-node replicasets on the localhost for testing
- name: Ensure replicaset replica0 exists
  mongodb_replicaset:
    login_host: localhost
    login_port: 3001
    login_user: admin
    login_password: root
    login_database: admin
    replica_set: replica0
    members: localhost:3000
    validate: yes

- name: Ensure replicaset replica1 exists
  mongodb_replicaset:
    login_host: localhost
    login_port: 3002
    login_user: admin
    login_password: secret
    login_database: root
    replica_set: replica1
    members: localhost:3001
    validate: yes

W naszym poradniku możemy nazwać zadania takie jak

---
- hosts: ansible-test
  remote_user: root
  become: yes
  Tasks:
- include: tasks.yml

Jeśli uruchomisz to w swoim playbook, ansible-playbook -i Inventory.txt -c ssh mongodbcreateReplcaSet.yaml otrzymasz odpowiedź, czy zestaw replik został utworzony, czy nie. Jeśli klucz mongodb_replicaset zostanie zwrócony z wartością powodzenia i opisem utworzonego zestawu replik, to dobrze jest iść.

Wniosek

W MongoDB generalnie żmudne jest konfigurowanie zestawu replik dla instancji mongod, które mogą być hostowane przez różne maszyny. Jednak Ansible zapewnia prostą platformę do robienia tego samego, po prostu definiując kilka parametrów, jak omówiono powyżej. Replikacja jest jednym z procesów zapewniających ciągłość działania aplikacji, dlatego powinna być dobrze skonfigurowana poprzez ustawienie wielu członków w świecie produkcyjnym. Arbiter jest używany do tworzenia kworum podczas procesu wyborczego, dlatego powinien zostać uwzględniony w pliku konfiguracyjnym poprzez określenie jego pozycji.