Wdrożenie wysokiej dostępności Nextcloud z Galera to skoordynowany system, a nie tylko trzy serwery baz danych. Potrzebne są również redundantne węzły aplikacji Nextcloud, współdzielona i trwała warstwa plików i danych, rozproszone buforowanie i blokowanie plików, równoważenie obciążenia, monitorowanie oraz przetestowane kopie zapasowe. Galera może utrzymać dostępność usługi bazy danych po awarii węzła bazy danych, gdy kworum pozostaje, ale nie może zapewnić wysokiej dostępności pozostałych komponentów.
W tym przewodniku zastosowano niezależny od dostawcy projekt systemu Linux z MariaDB Galera oraz odwrotnym serwerem proxy lub modułem równoważenia obciążenia. Nazwy pakietów, nazwy usług, ścieżki dostawców Galera, polecenia bootstrap i integracje sprawdzania kondycji serwera proxy różnią się w zależności od dystrybucji i wersji MariaDB. Przed wdrożeniem należy je zweryfikować z dokumentacją konkretnej wersji. Aktualny podręcznik administracji stabilnej Nextcloud wymienia PostgreSQL i MariaDB jako zalecane silniki baz danych i ostrzega o różnicach w obsługiwanych wersjach; sprawdź wymagania systemowe Nextcloud dla planowanej wersji. Niniejszy artykuł został sprawdzony pod kątem podręcznika Nextcloud 35 w wersji stabilnej z 6 października 2026 r.
Galera to synchroniczna, wielopodstawowa replikacja dla serwerów zgodnych z MySQL. Transakcja jest certyfikowana w całym klastrze, co pomaga zachować spójność elementów, ale zwiększa narzut koordynacyjny, a transakcje, które mogą kolidować, mogą zostać odrzucone. Dodawanie węzłów bazy danych nie zwiększa automatycznie przepustowości Nextcloud. Wskazówki dla deweloperów Nextcloud wskazują, że klastry generują koszty wydajności, a baza danych i pamięć masowa pozostają kluczowymi zasobami współdzielonymi.
| Wybór projektu | Dobrze pasuje | Główny kompromis |
|---|---|---|
| Jeden serwer MariaDB lub PostgreSQL | Małe wdrożenia wymagające najprostszych operacji | Konserwacja lub awaria bazy danych może przerwać świadczenie usługi |
| MariaDB z Galerą | Zespoły, które potrzebują redundancji węzłów bazy danych i potrafią obsługiwać procedury kworum, sieci, proxy i odzyskiwania | Więcej ruchomych części, koordynacja pisania, obsługa konfliktów i złożoność odzyskiwania |
| Dwa węzły bazy danych plus arbiter | Witryny z dokładnie dwoma hostami baz danych, ale oddzielną domeną awarii dla głosowania kworum | Arbiter pomaga w ustaleniu kworum, nie przechowuje danych ani nie zastępuje trzeciej kopii bazy danych |
| Galera za serwerem proxy obsługującym bazę danych | Wdrożenia wymagające stabilnego punktu końcowego połączenia i kontrolowanego routingu | Kontrole stanu serwera proxy i reguły routingu stają się kolejną usługą do obsługi |
W przypadku nowej instalacji, klaster Galera z trzema węzłami danych na niezależnych hostach jest częstym punktem wyjścia, o ile zespół operacyjny może go obsłużyć. Kworum Galera wymaga większości: klaster dwuwęzłowy nie może automatycznie i bezpiecznie przełączyć się na tryb failover po utracie jednego elementu. Trzy węzły mogą tolerować niedostępność jednego elementu, podczas gdy pozostałe dwa pozostają połączone. W miarę możliwości umieszczaj węzły w domenach awaryjnych, ale nie rozciągaj replikacji synchronicznej na łącza o dużym opóźnieniu bez przeprowadzenia testów. W środowisku o niższej złożoności, preferuj obsługiwaną pojedynczą bazę danych oraz dobrze przetestowany plan tworzenia kopii zapasowych i odzyskiwania.
Wypisz awarie, które chcesz przetrwać: proces webowy, host webowy, host bazy danych, moduł równoważenia obciążenia, punkt końcowy pamięci masowej, ścieżka sieciowa lub cała witryna. Określ cele odzyskiwania dla każdej z nich. Projekt z trzema węzłami bazy danych i jednym modułem równoważenia obciążenia nie jest w pełni redundantny. Podobnie jest w przypadku klastra aplikacji, którego pliki użytkownika znajdują się tylko na lokalnym dysku jednego serwera webowego.
Używaj spójnej wersji Nextcloud, środowiska uruchomieniowego PHP, zestawu aplikacji i konfiguracji na każdym węźle aplikacji. Wybierz wersje MariaDB i Galera, które są ze sobą kompatybilne i obsługiwane przez wybraną wersję Nextcloud. Wymagania bazy danych Nextcloud obejmują InnoDB, izolację transakcji READ COMMITTED oraz wyłączony logowanie binarne lub format ROW; nie kopiuj wartości dostrajających z innej wersji bez sprawdzenia aktualnych wymagań.
Utwórz prywatne nazwy DNS lub stabilne adresy dla każdego elementu bazy danych, każdego węzła internetowego, usługi pamięci podręcznej, współdzielonej pamięci masowej i publicznego punktu końcowego. Zarezerwuj oddzielny stabilny punkt końcowy bazy danych dla węzłów PHP Nextcloud. Przechowuj aplikacje, replikację i ruch publiczny na odpowiednio oddzielonych ścieżkach sieciowych, o ile pozwala na to infrastruktura. Nazwa węzła musi być unikatowa, a każdy element klastra musi spójnie rozwiązywać połączenia równorzędne Galera.
Zainstaluj MariaDB Server i dostawcę Galera, korzystając z repozytorium dostawcy zalecanego dla Twojego systemu operacyjnego. Zachowaj tę samą główną rodzinę serwerów i dostawców na wszystkich elementach. Nie łącz dowolnych pakietów społecznościowych z oddzielnie pobraną biblioteką dostawcy. Przed kontynuowaniem sprawdź obsługiwaną ścieżkę aktualizacji, metodę SST, jednostkę serwisową i katalog dołączania konfiguracji dla danego zestawu pakietów.
Ustaw serwer tak, aby korzystał z InnoDB i poziomu izolacji transakcji READ COMMITTED. Użyj rejestrowania binarnego ROW, jeśli jest ono włączone. Sprawdź wartości efektywne po ponownym uruchomieniu, zamiast zakładać, że plik konfiguracyjny został dołączony. Nextcloud dokumentuje te wymagania w swoim przewodniku konfiguracji bazy danych i wymaganiach systemowych .
Użyj referencji konfiguracji dostawcy, aby ustawić nazwę klastra, listę adresów równorzędnych, unikalną nazwę i adres każdego węzła, bibliotekę dostawcy oraz metodę przesyłania migawek stanu (SST). SST to proces, który dostarcza dołączającemu węzłowi stan bazy danych. Typowa konfiguracja klastra MariaDB zawiera opcje z tej rodziny:
[mariadb]
wsrep_on=ON
wsrep_cluster_name=nextcloud-cluster
wsrep_cluster_address=gcomm://db1.example.net,db2.example.net,db3.example.net
wsrep_node_name=db1
wsrep_node_address=db1.example.net
wsrep_sst_method=mariabackup
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
transaction_isolation=READ-COMMITTEDZmień wartości specyficzne dla węzła na każdym serwerze. Ścieżki dostawców i obsługiwane metody SST zależą od zainstalowanych pakietów; użyj udokumentowanej metody i poświadczeń dla swojej wersji. Chroń poświadczenia SST, certyfikaty i hasła do bazy danych jako sekrety. Nigdy nie używaj pustego adresu klastra jako stałego ustawienia: MariaDB dokumentuje, że może to spowodować, że serwer uruchomi nowy klaster zamiast ponownie dołączyć do istniejącego.
Zezwól warstwie sieciowej na dostęp tylko do punktu końcowego usługi bazy danych i zezwól członkom bazy danych na wzajemną komunikację na portach replikacji i transferu stanu Galera wymaganych przez wybranego dostawcę i metodę SST. Typowe wdrożenia Galera używają protokołu TCP i, w zależności od ustawień dostawcy, UDP do komunikacji grupowej; odpowiednie wartości domyślne często obejmują 4567 dla replikacji, 4568 dla przyrostowego transferu stanu i 4444 dla transferu migawek stanu. Traktuj je jako listę kontrolną do weryfikacji pod kątem wersji i konfiguracji, a nie jako powód do szerokiego otwierania wszystkich portów. Zachowaj port SQL jako prywatny i odmów dostępu publicznego.
Zainicjuj klaster dokładnie raz, używając procedury bootstrapowej udokumentowanej w pakiecie MariaDB Twojej dystrybucji. Po potwierdzeniu, że pierwszy element stanowi komponent główny, uruchom pozostałe elementy w sposób standardowy, aby dołączyły do niego i odebrały stan za pośrednictwem IST lub SST. IST przesyła brakujące zestawy zapisu, gdy są dostępne; SST wykonuje pełny transfer stanu. Nie uruchamiaj każdego hosta niezależnie i nie traktuj restartu jako akcji bootstrapowej.
Uruchom to zapytanie na każdym elemencie bazy danych po jego dołączeniu:
SHOW GLOBAL STATUS WHERE Variable_name IN
('wsrep_cluster_status','wsrep_cluster_size','wsrep_ready',
'wsrep_connected','wsrep_local_state_comment');Sprawdź, czy każdy węzeł jest połączony i gotowy, należy do komponentu głównego, zgłasza oczekiwany rozmiar klastra i osiągnął stan synchronizacji. MariaDB wyjaśnia te wskaźniki w swoim przewodniku monitorowania Galera .
Utwórz bazę danych z zestawem znaków i sortowaniem wymaganym przez aktualną instrukcję instalacji Nextcloud. Utwórz dedykowanego użytkownika bazy danych ograniczonego do sieci aplikacji i nadaj mu tylko uprawnienia wymagane do konfiguracji i normalnego działania Nextcloud. Użyj protokołu TLS w przypadku połączeń między hostami lub niezaufanymi segmentami sieci i zweryfikuj certyfikaty tam, gdzie obsługuje to wdrożenie. Nie umieszczaj poświadczeń root w pliku config.php.
Zainstaluj tę samą wersję kodu Nextcloud, rozszerzenia PHP, włączone aplikacje i konfigurację serwera na każdym węźle internetowym. Skonfiguruj jeden współdzielony punkt końcowy bazy danych, a nie różne hosty bazy danych w plikach dla każdego węzła. Wszystkie węzły muszą używać tego samego identyfikatora instancji, klucza tajnego, soli, polityki zaufanej domeny i innych ustawień dla całej instancji. Przechowuj konfigurację w kontrolowanym, współdzielonym procesie wdrażania lub dystrybuuj ją bezpiecznie, aby aktualizacje pozostały identyczne.
Warstwa plików i danych użytkownika musi być również wspólna dla węzłów aplikacji. Należy używać obsługiwanego współdzielonego systemu plików lub obsługiwanego projektu podstawowej pamięci masowej obiektów, który odpowiada wersji Nextcloud i wymaganiom operacyjnym. Dane użytkownika dostępne lokalnie na jednym hoście internetowym uniemożliwiają przełączenie awaryjne: żądanie skierowane do innego hosta nie zobaczy tych samych plików. Należy zachować rozróżnienie kodu aplikacji i ścieżek danych do zapisu oraz zweryfikować semantykę blokowania plików i pamięci masowej przed rozpoczęciem produkcji.
Nextcloud zazwyczaj tworzy ustawienia bazy danych podczas instalacji. Gdy punkt końcowy bazy danych i współdzielona pamięć masowa będą gotowe, należy sprawdzić, czy każdy węzeł rozpoznaje te same wartości. Przykładowy fragment konfiguracji wygląda następująco; należy zachować prawdziwe dane uwierzytelniające w chronionym przepływie pracy zarządzania tajnymi danymi i nie wklejać tego fragmentu w istniejącej konfiguracji produkcyjnej:
'dbtype' => 'mysql',
'dbname' => 'nextcloud',
'dbhost' => 'db-vip.internal:3306',
'dbuser' => 'nextcloud',
'dbpassword' => 'REPLACE_WITH_SECRET',
'datadirectory' => '/srv/nextcloud-data',
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
'host' => 'redis.internal',
'port' => 6379,
'password' => 'REPLACE_WITH_SECRET',
],Dostosuj zaplecze pamięci podręcznej i wybrany katalog danych do obsługiwanych opcji w swojej wersji NextCloud. Zainstaluj i skonfiguruj wymagane rozszerzenia PHP, jeśli ma to zastosowanie.
W razie potrzeby użyj APCu do lokalnego buforowania na hoście oraz współdzielonej usługi kompatybilnej z Redis, takiej jak Redis lub Valkey, do rozproszonego buforowania i blokowania plików transakcyjnych. Wszystkie węzły webowe muszą odwoływać się do tej samej usługi buforowania lub obsługiwanego klastra buforowania, a nie do hosta lokalnego. Nextcloud dokumentuje konfigurację klastra Redis dla konfiguracji klastrowych i zaznacza, że w przeciwnym razie blokowanie plików transakcyjnych domyślnie korzysta z bazy danych. Zabezpiecz pamięć podręczną za pomocą ograniczeń sieciowych, uwierzytelniania i protokołu TLS, tam gdzie to właściwe; dostępność pamięci podręcznej i mechanizmy przełączania awaryjnego wymagają osobnego projektu.
Skieruj Nextcloud do jednego stabilnego punktu końcowego udostępnianego przez serwer proxy bazy danych lub inną obsługiwaną warstwę routingu. Serwer proxy powinien zaprzestać wysyłania nowych połączeń do węzłów, które nie znajdują się w komponencie głównym, nie są zsynchronizowane lub nie są gotowe. Podstawowe sprawdzenie portu TCP jedynie potwierdza, że gniazdo akceptuje połączenia; nie potwierdza, że Galera może bezpiecznie obsługiwać aplikację. Sprawdź działanie kontroli stanu i tryby awarii wybranego serwera proxy. Jeśli używasz prostego modułu równoważenia obciążenia TCP, połącz go z niezawodnym sprawdzaniem gotowości Galera i konserwatywnymi regułami routingu.
Nie dodawaj rozdzielenia odczytu/zapisu ani routingu typu round-robin pochopnie. Podręcznik programisty Nextcloud opisuje obsługę połączeń podstawowych/replik i ostrzega, że odczyty tras w klastrze mogą powodować problemy ze spójnością, jeśli dane nie zostały rozpropagowane lub jeśli serwer proxy nie może przechowywać odczytów transakcyjnych na odpowiednim węźle. Zacznij od stabilnego punktu końcowego z możliwością zapisu, zmierz go i wprowadź specjalistyczny routing dopiero po zrozumieniu konsekwencji dla spójności i obsługi.
Umieść co najmniej dwa węzły webowe za modułem równoważenia obciążenia i użyj oddzielnego mechanizmu dostępności dla samego modułu, takiego jak usługa zarządzana, redundantna para lub przetestowany projekt wirtualnego adresu IP. Skonfiguruj zakończenie protokołu TLS, rozmiar żądania i zachowanie limitu czasu oraz wymagania dotyczące sesji trwałych zgodnie z wdrożeniem. Zapoznaj się z dokumentacją odwrotnego serwera proxy Nextcloud i ustaw trusted_proxiesna rzeczywiste adresy proxy; zaufanie dowolnym zakresom klientów osłabia obsługę adresów IP klientów.
Najpierw przetestuj aktualizacje na kopii przejściowej o tej samej topologii. Przestaw Nextcloud w tryb konserwacji, gdy wymaga tego procedura aktualizacji, zastosuj tę samą wersję aplikacji na każdym węźle i przywróć węzły do działania dopiero po pomyślnym przejściu kontroli stanu. W przypadku rutynowej konserwacji hosta, opróżnij po jednym węźle internetowym na raz i upewnij się, że pozostała pojemność jest wystarczająca. Aktualizacje bazy danych należy przeprowadzać za pomocą obsługiwanego procesu aktualizacji ciągłej MariaDB/Galera dla konkretnych wersji; nie należy tworzyć kolejności na podstawie ogólnego samouczka.
Utwórz kopię zapasową bazy danych i warstwy danych plików użytkownika, stosując udokumentowaną procedurę spójną z aplikacją. Zachowaj konfigurację, materiał szyfrujący i poufne dane w sposób dostępny dla autoryzowanych operatorów odzyskiwania. Replika Galera nie jest kopią zapasową: przypadkowe usunięcie i uszkodzenie logiczne mogą zostać zreplikowane do każdego elementu. Przechowuj kopie zapasowe poza domeną awarii klastra i regularnie przeprowadzaj próby przywracania. Galera dokumentuje kwestie związane z transferem stanu i tworzeniem kopii zapasowych w swoich wytycznych dotyczących tworzenia kopii zapasowych klastra ; sprawdź, czy każda przyjęta procedura obsługuje daną wersję MariaDB.
Galera to praktyczny wybór, gdy potrzebna jest redundancja węzłów bazy danych, istnieje wiele domen awarii oraz można monitorować kworum i ćwiczyć kontrolowane odzyskiwanie. Może się jednak okazać nieodpowiednim rozwiązaniem, gdy głównym celem są prostsze operacje, gdy obciążenie bazy danych jest zdominowane przez konflikty zapisów lub gdy zespół nie może bezpiecznie zareagować na utratę kworum. W takich przypadkach prostsze wdrożenie bazy danych z solidnymi kopiami zapasowymi lub zarządzana usługa bazy danych mogą zapewnić lepszą niezawodność operacyjną.
W przypadku mniejszej, samodzielnie hostowanej usługi, należy najpierw zapewnić wymienność węzłów aplikacji, przenieść pliki użytkowników do trwałej, współdzielonej pamięci masowej, skonfigurować współdzielone blokowanie Redis i przetestować kopie zapasowe. Dodaj Galerę dopiero wtedy, gdy pomiary wykażą, że awaria pojedynczego węzła bazy danych lub przerwa konserwacyjna stanowi niedopuszczalne ryzyko i organizacja może utrzymać dodatkową warstwę. Istotnym testem sukcesu nie jest „wszystkie trzy serwery bazy danych działają”, ale to, czy adres URL Nextcloud pozostaje użyteczny podczas planowanej utraty węzła, przesyłanie i pobieranie danych działa na węzłach internetowych, baza danych zachowuje kworum, a zespół może przywrócić zarówno dane bazy danych, jak i pliki z kopii zapasowej.
Porównaj 10 narzędzi do pingowania, które umożliwiają szybkie wykrywanie sieci LAN, skanowanie międzyplatformowe i zarządzanie adresami IP. Dowiedz się, co narzędzie pingujące może Ci powiedzieć, a czego nie.
Porównaj sześć narzędzi do zarządzania siecią służących do monitorowania wydajności, obejmujących zasięg SNMP, mapowanie, alerty, modele wdrażania i kompromisy kosztów.
Porównaj siedem darmowych i otwartych monitorów pingów — od kompletnych pakietów sieciowych po ukierunkowane sondy opóźnień — i wybierz odpowiedni monitor pod kątem dostępności, utraty pakietów i historii.
Dowiedz się, co oznacza QoS w sieciach, w jaki sposób oznaczenia DSCP i kolejki ruchu nadają priorytet aplikacjom głosowym, wideo i biznesowym oraz czego QoS nie jest w stanie naprawić.
Porównaj niezawodne oprogramowanie serwera SFTP dla systemów Windows i Linux, w tym OpenSSH, Bitvise, SolarWinds i SFTPGo. Znajdź rozwiązanie odpowiednie dla swoich potrzeb w zakresie bezpieczeństwa i transferu plików.
Porównaj siedem narzędzi do zarządzania adresami IP służących do wykrywania podsieci, koordynacji DNS i DHCP, inwentaryzacji sieci i otwartego oprogramowania IPAM.
Porównaj sześć narzędzi do monitorowania systemu Windows Server pod kątem zbierania danych systemu Windows, widoczności aplikacji, modelu wdrażania i licencjonowania, aby znaleźć odpowiednie rozwiązanie.
Porównaj narzędzia do skanowania sieciowego umożliwiające szybkie wykrywanie urządzeń, skanowanie adresów IP na wielu platformach oraz zarządzanie IPAM w przedsiębiorstwie. Znajdziesz tu wskazówki dotyczące dopasowania każdej opcji do swojej sieci.
Zbuduj praktyczny monitoring sieci z przejrzystym zakresem urządzeń, przydatnymi wskaźnikami wydajności, przydatnymi alertami oraz porównaniem SolarWinds NPM, PRTG i OpManager.
Użyj opcji --traceroute programu Nmap, aby mapować przeskoki do autoryzowanego hosta, zrozumieć dane wyjściowe dotyczące przeskoków i czasu RTT oraz rozwiązywać problemy z brakującymi odpowiedziami bez nadmiernego skanowania.
