Zbuduj odporny klaster Nextcloud z Galera

Najpierw zbuduj klaster bazy danych, a następnie umieść wiele identycznych węzłów aplikacji Nextcloud za systemem równoważenia obciążenia o sprawdzonej kondycji. Aby zapewnić stabilną konfigurację, wszystkie węzły aplikacji muszą korzystać z tego samego trwałego magazynu plików, konfiguracji, usługi blokowania Redis lub Valkey oraz punktu końcowego bazy danych, który kieruje zapisy tylko do sprawnego elementu Galera. Aktualny podręcznik administratora Nextcloud wymienia MariaDB jako obsługiwaną bazę danych, ale nie publikuje receptury wdrożenia specyficznej dla Galera; przed rozpoczęciem produkcji sprawdź dokładne wersje Nextcloud, MariaDB, Galera i proxy u dostawców.

Stan na 9 października 2026 r. na stronie z wymaganiami systemowymi Nextcloud 35 wymieniono MariaDB 10.11, 11.4, 11.8 i 12.3, przy czym wersja 12.3 została oznaczona jako zalecana. Jest to lista wersji bazy danych Nextcloud, a nie gwarancja, że ​​każda kombinacja Galera lub proxy jest certyfikowana. Zacznij od wymagań systemowych Nextcloud 35 i macierzy wsparcia Galera dla swojej dystrybucji MariaDB.

1. Określ granice awarii

Klaster o wysokiej dostępności to coś więcej niż tylko replikowana baza danych. Galera chroni warstwę bazy danych; nie replikuje plików użytkowników NextCloud, sesji PHP, blokad Redis ani kodu aplikacji. Pojedyncza, współdzielona baza danych nie jest również w stanie zrekompensować nieudanego podłączenia pamięci masowej ani modułu równoważenia obciążenia, który nadal wysyła ruch do uszkodzonego węzła aplikacji.

Przed instalacją zaplanuj następujące komponenty:

• Co najmniej dwa serwery aplikacji wykorzystujące tę samą wersję Nextcloud, tę samą wersję PHP, włączone aplikacje i konfigurację internetową.
• Moduł równoważenia obciążenia lub odwrotny serwer proxy ze stabilną publiczną nazwą hosta, protokołem HTTPS i kontrolami kondycji serwerów aplikacji.
• Współdzielona, ​​trwała pamięć masowa danych Nextcloud widoczna w tej samej ścieżce i z odpowiednimi uprawnieniami na każdym serwerze aplikacji. Katalog danych Nextcloud należy ustawić podczas instalacji; instrukcje instalacji ostrzegają, że jego późniejsze przeniesienie może być trudne.
• Klaster Galera z nieparzystą liczbą węzłów bazy danych do głosowania, zazwyczaj trzema, rozmieszczonymi w taki sposób, aby awaria jednego hosta nie spowodowała usunięcia większości.
• Współdzielona usługa Redis lub Valkey do rozproszonego buforowania i transakcyjnych blokad plików.

Wybierz projekty pamięci masowej i sieci z własną redundancją i przetestowanym odzyskiwaniem. Ścieżka współdzielona nie jest automatycznie wysoce dostępna tylko dlatego, że kilka serwerów WWW może ją zamontować.

2. Najpierw zainstaluj i zweryfikuj MariaDB Galera

Wybierz wersję MariaDB, która spełnia aktualne wymagania Nextcloud, oraz pasujący pakiet Galera obsługiwany przez Twojego dostawcę MariaDB. Postępuj zgodnie z dokumentacją wdrożenia MariaDB Galera dotyczącą konfiguracji węzłów, portów sieciowych, transferu migawek stanu, protokołu TLS i początkowego bootstrapu. Nie uruchamiaj każdego pustego węzła jako nowego klastra; załaduj jeden węzeł, a następnie dołącz pozostałe do tego klastra.

Nextcloud wymaga InnoDB oraz READ-COMMITTEDpoziomu izolacji transakcji dla MySQL lub MariaDB. Aktualna strona bazy danych Nextcloud zaleca również logowanie binarne oparte na wierszach. Sprawdź wartości na każdym węźle bazy danych, nie tylko na tym, który aktualnie odbiera ruch. Zobacz wymagania konfiguracyjne Nextcloud MariaDB .

Przed połączeniem z NextCloud sprawdź stan klastra na każdym węźle. Na przykład uruchom SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status';i SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';. Klaster powinien zgłosić Primarykomponent, oczekiwany rozmiar klastra oraz węzły w Syncedstanie. MariaDB wyjaśnia, że ​​kworum wymaga ponad połowy ostatniego znanego członkostwa w klastrze; klaster trzywęzłowy może zatem tolerować utratę jednego węzła, a nie dwóch. Zapoznaj się z wytycznymi dotyczącymi kworum i odzyskiwania .

3. Zapewnij Nextcloud punkt końcowy bazy danych uwzględniający stan zdrowia

Skonfiguruj Nextcloud tak, aby łączył się ze stabilnym adresem proxy bazy danych, a nie z listą adresów IP Galera. Chociaż Galera replikuje zapisy w całym klastrze, aplikacje nadal potrzebują przewidywalnej obsługi transakcji. Serwer proxy monitorujący członkostwo w Galera może zatrzymać routing do węzłów niedostępnych lub niezsynchronizowanych i wybrać węzeł zapisu. Monitor Galera w MariaDB MaxScale to jedna z udokumentowanych opcji; jego dokładne działanie i obsługiwane tryby routingu zależą od wersji i konfiguracji MaxScale.

Użyj udokumentowanego punktu końcowego połączenia serwera proxy, takiego jak w NextCloud dbhost. Twórz oddzielne konta o najniższych uprawnieniach do monitorowania i dostępu do aplikacji, chroń dane uwierzytelniające i szyfruj ruch w bazie danych, gdy przechodzi przez niezaufaną sieć. Unikaj włączania podziału odczytu/zapisu jako domniemanego skrótu wydajnościowego: własna funkcja replikacji NextCloud wysyła odczyty do replik, jednocześnie zachowując zapisy i odczyty przyczynowe w domyślnym połączeniu, ale Galera nie jest zwykłym asynchronicznym układem replik. Użyj projektu routingu przetestowanego specjalnie dla Twojego stosu.

4. Spraw, aby każdy węzeł aplikacji widział tę samą instancję NextCloud

Zainstaluj ten sam kod Nextcloud i zestaw aplikacji na każdym serwerze aplikacji. Zachowaj spójność każdego węzła config.phpdla współdzielonej instancji, w tym punktu końcowego bazy danych, wartości tajnych, zaufanych domen i ścieżki do katalogu danych. Nie uruchamiaj aktualizacji niezależnie na wielu węzłach. Najpierw utwórz kopię zapasową, przełącz instancję w tryb konserwacji, wykonaj aktualizację za pomocą jednej kontrolowanej ścieżki i przywróć ruch dopiero po uruchomieniu tej samej wersji na wszystkich węzłach.

Skonfiguruj wszystkie węzły aplikacji tak, aby korzystały z tej samej usługi Redis lub Valkey do rozproszonej pamięci podręcznej i blokowania. Lokalna pamięć podręczna, taka jak APCu, może pozostać lokalna dla węzła, ale memcache.distributedmusi memcache.lockingwskazywać na wspólną usługę, a nie na serwer localhost. Na przykład konfiguracja Redis w NextCloud może korzystać 'memcache.locking' => '\OC\Memcache\Redis'ze współdzielonego hosta Redis redis. Postępuj zgodnie z aktualnym przewodnikiem konfiguracji pamięci podręcznej i przewodnikiem blokowania plików transakcyjnych . Memcached nie nadaje się do blokowania plików transakcyjnych w NextCloud.

Jeśli centralizujesz również sesje PHP w Redis, potraktuj to jako osobne zadanie konfiguracji PHP. Podręcznik NextCloud ostrzega, że ​​blokowanie sesji nie jest domyślnie włączone dla modułu obsługi sesji Redis; zastosuj jego ustawienia blokowania i przetestuj działanie sesji przed jego użyciem. Nie należy mylić replikacji bazy danych ani blokowania plików z ciągłością sesji.

5. Przetestuj tryb failover przed nazwaniem go wysoce dostępnym

Najpierw potwierdź normalne użytkowanie za pomocą publicznej nazwy hosta: zaloguj się, prześlij i pobierz plik testowy, a następnie sprawdź, czy jest on widoczny po dotarciu żądania do innego węzła aplikacji. Następnie odłącz jeden węzeł sieciowy i potwierdź, że żądania są kontynuowane przez drugi. Przywróć go i upewnij się, że ponownie się łączy, nie wyświetlając nieaktualnego kodu ani wersji konfiguracji.

Następnie użyj okna konserwacyjnego, aby zasymulować awarię jednego węzła bazy danych zgodnie z podręcznikiem dostawcy. Upewnij się, że serwer proxy usunie uszkodzony lub niezsynchronizowany element, Nextcloud będzie nadal mógł odczytywać i zapisywać, a węzeł powracający osiągnie punkt docelowy Syncedprzed zaakceptowaniem ruchu. Monitoruj stan główny Galera, rozmiar klastra, synchronizację węzłów, kondycję serwera proxy, błędy aplikacji i stan montowania pamięci masowej.

Utrata kworum to zabezpieczenie, a nie dowód utraty danych. Nie należy wymuszać bootstrapu wielu węzłów ani wybierać jednego losowo. Przewodnik odzyskiwania danych MariaDB zaleca zidentyfikowanie najbardziej zaawansowanego węzła i bootstrapu tylko tego węzła, a następnie ponowne połączenie pozostałych. Upewnij się, że przetestowałeś również kopie zapasowe bazy danych i magazynu plików; replikacja Galera odzwierciedla zmiany w bazie danych i nie zastępuje kopii zapasowych z określonego punktu w czasie.

Sprawdź wynik

Konfiguracja jest gotowa do produkcji dopiero wtedy, gdy jeden węzeł aplikacji i jeden węzeł bazy danych można usunąć bez zakłócania normalnych operacji na plikach, wszystkie pozostałe węzły Galera pozostają w komponencie podstawowym, a współdzielony magazyn plików oraz usługi Redis lub Valkey pozostają dostępne. Jeśli test się nie powiedzie, przed zmianą limitów czasu lub ustawień ponawiania prób należy zidentyfikować, która warstwa przestała obsługiwać żądanie. Podręcznik Nextcloud dokumentuje obsługiwane ustawienia bazy danych i aplikacji, a macierz zgodności dostawców i testy przełączania awaryjnego określają, czy dane wdrożenie Galera jest obsługiwane.