Serwery wirtualizacyjne bazujące na systemach z rodziny Debian, takie jak Proxmox, są często używane w środowiskach testowych, gdzie ciągła dostępność jest kluczowa. Czasami te serwery są instalowane na laptopach, które są wykorzystywane jako niskobudżetowe lub przenośne rozwiązania. Standardowe ustawienia zarządzania energią w laptopach mogą jednak prowadzić do niepożądanych zachowań, takich jak uśpienie lub hibernacja przy zamknięciu pokrywy. Poniżej opisuję, jak zmienić te ustawienia w systemie operacyjnym bazującym na Debianie, aby zapewnić nieprzerwaną pracę serwera.
Krok 1: Dostęp do pliku konfiguracyjnego
Otwórz terminal i wpisz poniższe polecenie, aby edytować plik /etc/systemd/logind.conf przy użyciu edytora tekstowego (np. nano):
Edycja logind
Shell
1
nano/etc/systemd/logind.conf
Krok 2: Modyfikacja ustawień logind
Znajdź linijkę zawierającą HandleLidSwitch i zmień jej wartość na ignore. Jeśli linia jest zakomentowana (poprzedzona znakiem #), usuń znak #. Możesz również dodać tę linię na końcu pliku, jeśli nie istnieje.
Shell
1
HandleLidSwitch=ignore
Krok 3: Zastosowanie i restart usługi
Po wprowadzeniu zmian i zapisaniu pliku, należy zrestartować usługę systemd-logind, aby zmiany weszły w życie. Użyj poniższego polecenia w terminalu:
Resetowanie systemd-logind
Shell
1
systemctl restart systemd-logind
Dzięki tym zmianom, zamknięcie pokrywy laptopa nie będzie już inicjować hibernacji ani uśpienia, co jest szczególnie ważne w przypadku korzystania z serwerów bazujących na Debianie, w tym Proxmox, jako rozwiązania serwerowe.
Zarządzanie pamięcią SWAP jest kluczowym elementem administrowania systemami operacyjnymi Linux, szczególnie w środowiskach wirtualizacji takich jak Proxmox. SWAP służy jako „pamięć wirtualna”, która może być używana, gdy fizyczna pamięć RAM systemu jest zapełniona. W tym artykule pokażemy, jak zwiększyć przestrzeń SWAP na serwerze Proxmox, korzystając z narzędzia lvresize do zwolnienia miejsca na dysku, które można następnie przeznaczyć na SWAP.
Przegląd problemu
Użytkownik chce zwiększyć przestrzeń SWAP z 8 GB do 16 GB, ale napotyka problem braku dostępnej przestrzeni w grupie woluminów LVM, która jest wymagana do zwiększenia SWAP.
Krok 1: Sprawdzenie dostępnej przestrzeni
Shell
1
vgs
To polecenie wyświetla grupy woluminów wraz z ich rozmiarami i dostępną przestrzenią.
Krok 2: Zmniejszenie wolumenu
Załóżmy, że istnieje wolumen root o rozmiarze 457.26 GB, który można zmniejszyć, aby uzyskać dodatkowe 8 GB na SWAP. Przed zmniejszeniem wolumenu konieczne jest zmniejszenie systemu plików na tym wolumenie.
Shell
1
resize2fs/dev/pve/root449.26G
Jednakże w przypadku systemu plików XFS, zmniejszenie musi nastąpić w trybie offline lub z live CD.
Krok 3: Użycie lvreduce
Shell
1
lvreduce-L-8G/dev/pve/root
To polecenie zmniejszy wolumen root o 8 GB, co potwierdza się komunikatem o zmianie rozmiaru wolumenu.
Krok 4: Deaktywacja SWAP
Shell
1
swapoff-a
Przed rozpoczęciem zmian w rozmiarze SWAP, należy najpierw wyłączyć SWAP za pomocą powyższego polecenia.
Krok 5: Rozszerzenie SWAP
Shell
1
2
3
lvresize-L+8G/dev/pve/swap
mkswap/dev/pve/swap
swapon/dev/pve/swap
Powyższe polecenia najpierw zwiększają przestrzeń SWAP, następnie formatują ją i aktywują ponownie.
Shell
1
swapon--show
Na koniec, weryfikujemy aktywne obszary SWAP używając polecenia powyżej, aby upewnić się, że wszystko zostało poprawnie skonfigurowane.
Proces ten pokazuje, jak można elastycznie zarządzać przestrzenią dyskową na serwerach Proxmox, dostosowując rozmiar SWAP w zależności od potrzeb. Użycie lvreduce wymaga ostrożności, gdyż każde działanie na partycjach i woluminach niesie ryzyko utraty danych, dlatego zawsze zalecane jest wykonanie kopii zapasowych przed przystąpieniem do zmian.
Pracując z MySQL, można napotkać różne błędy, które mogą zakłócić działanie systemu. Kod błędu 1114 jest jednym z nich i wskazuje na sytuację, gdy tabela, do której użytkownik próbuje zapisać dane, jest pełna. Ten problem jest szczególnie znaczący w systemie replikacji MySQL, gdzie jego rozwiązanie jest kluczowe dla zapewnienia ciągłości pracy.
Opis problemu
Błąd 1114 manifestuje się komunikatem: „Could not execute Write_rows event on table docs; The table 'docs’ is full”. Oznacza to, że nowe wiersze nie mogą zostać zapisane z powodu przekroczenia rozmiaru tabeli tymczasowej. Szczegółowy komunikat błędu może wyglądać tak:
Zaloguj się do MySQL:
Login to mysql
Shell
1
# mysql -u root -p
Zmień wartości zmiennej:
MySQL zmiana tmp_table_size i max_heap_table_size
MySQL
1
2
SET GLOBALtmp_table_size=268435456;-- Ustawienie na 256M
SET GLOBALmax_heap_table_size=268435456;-- Ustawienie na 256M
Po wprowadzeniu tych zmian, wszystkie nowe połączenia do serwera MySQL będą używać tych zaktualizowanych wartości. Możesz je sprawdzić, wykonując:
MySQL sprawdzanie tmp_table_size i max_heap_table_size
MySQL
1
2
SHOWGLOBALVARIABLESLIKE'tmp_table_size';
SHOWGLOBALVARIABLESLIKE'max_heap_table_size';
Albo
MySQL sprawdzanie tmp_table_size i max_heap_table_size
MySQL
1
SELECT@@tmp_table_size,@@max_heap_table_size;
Teraz replikacje można wznowić i powinna lepiej działać. Jednak należy pamiętaj, o modyfikacji konfiguracji, aby po restarcie mysqla zmienne te zostały poprawnie ustawione. Może być koniecznie tutaj wznowienie np replikacji (jeśli wcześniej została zatrzymana):
MySQL slave
MySQL
1
START SLAVE;
Jeśli problem został rozwiązany, na tym etapie sprawdzenie stanu replikacji:
Przed restartem usługi zalecane jest wykonanie SHUTDOWN; w kliencie MySQL. Należy pamiętać o wznowieniu replikacji.
Ważne uwagi
Zasoby systemowe: Upewnij się, że serwer dysponuje wystarczającą ilością pamięci RAM do obsługi zwiększonych wartości zmiennych.
Monitoring wydajności: Po dokonaniu zmian monitoruj wydajność, aby sprawdzić, czy problem został rozwiązany.
Trwałość konfiguracji: Zmiany w pliku konfiguracyjnym powinny być trwałe, aby uniknąć resetowania wartości po restarcie.
Dodatkowe kroki sprawdzające
Sprawdzenie dostępnej przestrzeni dyskowej: Możliwe, że problem wynika również z braku dostępnej przestrzeni na dysku. Można to sprawdzić za pomocą poniższej komendy:
Sprawdzenie dysku
Shell
1
# df -h
Podsumowanie
Rozwiązanie problemu związanego z kodem błędu 1114 w replikacji MySQL wymaga zrozumienia i dostosowania konfiguracji systemu. Opisane kroki pokazują, jak poprzez zwiększenie rozmiaru tabeli tymczasowej można zapobiec występowaniu tego błędu, co umożliwia sprawne działanie systemu replikacji.
W dzisiejszych czasach, gdy dane stają się coraz bardziej wartościowe, odpowiednie zarządzanie backupami jest kluczowe dla bezpieczeństwa systemu informatycznego. W tym artykule przedstawiam skuteczny sposób na automatyzację backupu kluczowych plików konfiguracyjnych w systemach opartych na Proxmox za pomocą prostego skryptu bash oraz konfiguracji Crontab.
Skrypt Bash do Backupu Katalogu /etc
Plik /etc zawiera krytyczne pliki konfiguracyjne systemu, które są niezbędne do prawidłowego funkcjonowania systemu operacyjnego i różnych aplikacji. Utrata lub uszkodzenie tych plików może prowadzić do poważnych problemów. Poniżej prezentuję skuteczny skrypt backup-etc.sh, który pozwala na zautomatyzowane tworzenie kopii zapasowych tego katalogu:
Generuje aktualną datę i czas, które są dodawane do nazwy tworzonego archiwum, aby łatwo można było identyfikować poszczególne kopie.
Używa programu tar z kompresją zstd do stworzenia zarchiwizowanej i skompresowanej kopii katalogu /etc.
Usuwa archiwa starsze niż 100 dni z lokalizacji /var/lib/vz/dump/, dzięki czemu zapewniona jest optymalizacja przestrzeni dyskowej.
Dodanie Skryptu do Crontab
Aby automatyzować proces tworzenia backupu, skrypt należy dodać do crontaba. Poniżej znajduje się przykładowa konfiguracja, która uruchamia skrypt codziennie o 2:40 nad ranem:
Edytowanie crontaba
Shell
1
2
# crontab -e
402***/root/backup-etc.sh>/dev/null2>&1
Przekierowanie wyjścia do /dev/null zapewnia, że operacje są wykonywane cicho bez generowania dodatkowego outputu na standardowe wyjście.
Pobranie Skryptu z Serwisu soban.pl
Skrypt backup-etc.sh jest dostępny do pobrania również z serwisu soban.pl. Możesz go pobrać za pomocą poniższego polecenia wget i od razu zapisać jako plik /root/backup-etc.sh:
Dzięki temu prostemu poleceniu, skrypt zostanie pobrany z serwera i nadany odpowiednie uprawnienia wykonywalności.
Korzyści i Modyfikacje
Skrypt backup-etc.sh jest elastyczny i można go łatwo modyfikować do potrzeb różnych systemów. Jest on domyślnie umieszczony w folderze /var/lib/vz/dump/, który jest standardowym miejscem przechowywania backupów w środowiskach Proxmox. Dzięki temu zarządzanie kopiami zapasowymi jest uproszczone i można je łatwo zintegrować z istniejącymi rozwiązaniami backupowymi.
Trzymając backupy przez 100 dni, zapewniamy równowagę między dostępnością a zarządzaniem przestrzenią dyskową. Stare kopie są automatycznie usuwane, co minimalizuje ryzyko przepełnienia dysku i zmniejsza koszty przechowywania danych.
Podsumowanie
Automatyzacja backupu za pomocą skryptu bash i Crontab to efektywna metoda na zabezpieczenie krytycznych danych systemowych. Skrypt backup-etc.sh zapewnia prostotę, elastyczność i efektywność, co czyni go doskonałym rozwiązaniem dla administratorów systemów Proxmox. Zachęcam do adaptacji i modyfikacji tego skryptu zgodnie z własnymi potrzebami, aby zapewnić jeszcze lepsze zabezpieczenie swojego środowiska IT.
Aktualizacja Apache Cassandra do nowszej wersji to znaczące zadanie, które administratorzy baz danych podejmują, aby ich systemy korzystały z nowych funkcji, ulepszonych środków bezpieczeństwa i poprawionej wydajności. Ten przewodnik dostarcza szczegółowych instrukcji dotyczących aktualizacji Apache Cassandra z wersji 3.1.15 i wyższych do najnowszej wersji 4.1.x, specjalnie na Ubuntu 20.04.5 LTS, ze szczególnym naciskiem na operacje czyszczenia przed aktualizacją, aby efektywnie zarządzać przestrzenią dyskową.
Przygotowanie przed aktualizacją
Kopia zapasowa katalogu konfiguracyjnego:
Przed rozpoczęciem aktualizacji kluczowe jest wykonanie kopii zapasowej katalogu konfiguracyjnego Cassandry. To zabezpieczenie umożliwia szybkie przywrócenie konfiguracji, jeśli podczas procesu aktualizacji pojawią się jakiekolwiek problemy. Wykorzystaj poniższe polecenie, aby stworzyć kopię zapasową, włączając do nazwy folderu bieżącą datę dla łatwej identyfikacji:
Przygotowanie jest kluczem do płynnej aktualizacji. Zacznij od poleceń konserwacyjnych, aby zagwarantować integralność danych i zoptymalizować wykorzystanie przestrzeni, co jest szczególnie ważne dla systemów z ograniczoną przestrzenią dyskową.
Oczyszczanie danych:
Wykonaj nodetool scrub, aby oczyścić i zreorganizować dane na dysku. Biorąc pod uwagę, że ta operacja może być czasochłonna, zwłaszcza dla baz danych z dużą ilością danych lub ograniczoną przestrzenią dyskową, jest to kluczowy krok dla zdrowego procesu aktualizacji.
Usuwanie snapshota:
Aby dalej zarządzać przestrzenią dyskową, użyj nodetool clearsnapshot do usunięcia istniejących snapshota, zwalniając miejsce na proces aktualizacji. Aby usunąć wszystkie migawki na węźle, po prostu użyj tej metody, jeśli kończy Ci się miejsce:
clear all snapshot
Shell
1
# nodetool clearsnapshot --all
Czyszczenie danych:
Wykonaj nodetool cleanup, aby usunąć zbędne dane. W scenariuszach, gdzie przestrzeń dyskowa jest na wagę złota, zaleca się wykonanie operacji oczyszczania bez tworzenia migawki, aby oszczędzić miejsce:
scrub cassandra
Shell
1
# nodetool scrub --no-snapshot
Opróżnianie i zatrzymywanie Cassandry
Opróżnienie węzła:
Przed zatrzymaniem usługi Cassandra, upewnij się, że wszystkie dane w pamięci są zapisane na dysku za pomocą nodetool drain.
drain cassandra
Shell
1
# nodetool drain
Zatrzymaj usługę Cassandry:
Zatrzymaj działające usługi Cassandry, aby bezpiecznie przystąpić do aktualizacji:
drain cassandra
Shell
1
# systemctl stop cassandra.service
Aktualizacja Cassandry
Aktualizacja listy źródeł:
Edytuj źródła repozytorium, aby wskazywały na nową wersję Cassandry, dostosowując plik cassandra.sources.list:
Przy zaktualizowanych źródłach repozytorium, odśwież listę pakietów i zaktualizuj pakiety. Podczas wykonywania polecenia apt upgrade, możesz kontynuować naciskając Enter, ponieważ domyślna opcja to 'N’ (Nie):
Upgrade cassandra
Shell
1
# apt update && apt upgrade
Modyfikacja konfiguracji:
Dostosuj konfigurację Cassandry dla wersji 4.1.x, komentując lub usuwając przestarzałe opcje:
deleting deprecated options in cassandra
Shell
1
# for var in thrift_prepared_statements_cache_size_mb start_rpc rpc_port rpc_server_type thrift_framed_transport_size_in_mb request_scheduler; do sed -i "/$var:/s/^/#/" /etc/cassandra/cassandra.yaml; done
Aktualizacja biblioteki JAMM:
Upewnij się, że biblioteka Java Agent Memory Manager (JAMM) jest zaktualizowana, aby poprawić wydajność:
change jamm version in cassandra
Shell
1
# sed -i 's|jamm-0.3.0.jar|jamm-0.3.2.jar|g' /etc/cassandra/cassandra-env.sh
Zapasowa kopia i aktualizacja pliku opcji JVM:
Jest dobrą praktyką tworzenie kopii zapasowych plików konfiguracyjnych przed dokonaniem zmian. Ten krok zmienia nazwę istniejącego pliku jvm-server.options na jvm-server.options.orig jako kopię zapasową. Następnie kopiuje plik jvm.options do jvm-server.options, stosując standardowe opcje JVM dla serwerów Cassandry.
Po aktualizacji warto ocenić i zoptymalizować wykorzystanie pamięci i przestrzeni wymiany, aby zapewnić efektywne działanie Cassandry:
free ram
Shell
1
# swapoff -a && swapon -a
Uruchom ponownie usługę Cassandry:
start service cassandra
Shell
1
# systemctl start cassandra.service
Weryfikacja aktualizacji:
Potwierdź sukces aktualizacji, sprawdzając topologię i stan klastra, upewniając się, że wszystkie węzły są funkcjonalne:
verify upgrade of cassandra
Shell
1
2
# nodetool describecluster
# nodetool status
Przestrzegając tego szczegółowego przewodnika, administratorzy baz danych mogą skutecznie aktualizować Apache Cassandra do wersji 4.1.x, wykorzystując najnowsze postępy i optymalizacje, które platforma ma do zaoferowania, jednocześnie zapewniając integralność danych i wydajność systemu dzięki starannym przygotowaniom przed aktualizacją.
Optymalizacja i weryfikacja
Po pomyślnej aktualizacji Apache Cassandra do wersji 4.1.x i upewnieniu się, że klaster jest w pełni operacyjny, kluczowe jest przeprowadzenie konserwacji po aktualizacji, aby zoptymalizować wydajność i bezpieczeństwo systemu bazy danych. Ta sekcja przedstawia niezbędne kroki i rozważania, aby utrzymać zdrowe i efektywne środowisko Cassandry.
Monitorowanie wydajności i dzienników
Bezpośrednio po aktualizacji ściśle monitoruj wydajność systemu, w tym użycie procesora, pamięci i I/O dysków, aby zidentyfikować wszelkie nieoczekiwane zachowania lub wąskie gardła. Dodatkowo, przejrzyj dzienniki systemowe Cassandry pod kątem ostrzeżeń lub błędów, które mogą wskazywać na potencjalne problemy wymagające uwagi.
Regulacja i optymalizacja
Na podstawie wglądu w monitorowanie wydajności, możesz potrzebować dostosować ustawienia konfiguracyjne Cassandry dla optymalnej wydajności. Rozważ regulację parametrów związanych z opcjami JVM, kompaktacją i wydajnością odczytu/zapisu, mając na uwadze specyficzne obciążenie i wzorce danych Twojej aplikacji.
Uruchom nodetool upgradesstables
Aby upewnić się, że wszystkie SSTables są zaktualizowane do najnowszego formatu, wykonaj nodetool upgradesstables na każdym węźle w klastrze. Ta operacja przepisze SSTables, które nie są jeszcze w bieżącym formacie, co jest niezbędne do pełnego wykorzystania ulepszeń i funkcji w Cassandra 4.1.x (Sprawdź przestrzeń i w razie potrzeby usuń wszystkie migawki, jak pokazano powyżej.):
Upgrade sstables
Shell
1
# time nodetool upgradesstables
Ten proces może być obciążający dla zasobów i powinien być zaplanowany poza godzinami szczytu, aby zminimalizować wpływ na ruch na żywo.
Wdrożenie ulepszeń bezpieczeństwa
Cassandra 4.1.x zawiera kilka ulepszeń bezpieczeństwa. Przejrzyj najnowsze funkcje bezpieczeństwa i najlepsze praktyki, takie jak włączenie szyfrowania klient-serwer, szyfrowanie węzeł-węzeł oraz zaawansowane mechanizmy uwierzytelniania, aby poprawić poziom bezpieczeństwa klastra Cassandry.
Przegląd i aktualizacja strategii tworzenia kopii zapasowych
Z nową wersją na miejscu, ponownie ocen swoje strategie tworzenia kopii zapasowych, aby upewnić się, że są nadal skuteczne i spełniają Twoje cele odzyskiwania. Zweryfikuj, czy Twoje procedury tworzenia kopii zapasowych i przywracania są zgodne z Cassandra 4.1.x oraz rozważ wykorzystanie nowych narzędzi lub funkcji, które mogły zostać wprowadzone w tej wersji dla bardziej efektywnego zarządzania danymi.
