Jak zapobiegać hibernacji i uśpieniu na laptopach z debianem i proxmox podczas zamknięcia pokrywy

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):

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.

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:

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.

Rozszerzanie przestrzeni SWAP na Proxmoxie przy użyciu lvreduce

Wprowadzenie

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

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.

Jednakże w przypadku systemu plików XFS, zmniejszenie musi nastąpić w trybie offline lub z live CD.

Krok 3: Użycie lvreduce

To polecenie zmniejszy wolumen root o 8 GB, co potwierdza się komunikatem o zmianie rozmiaru wolumenu.

Krok 4: Deaktywacja SWAP

Przed rozpoczęciem zmian w rozmiarze SWAP, należy najpierw wyłączyć SWAP za pomocą powyższego polecenia.

Krok 5: Rozszerzenie SWAP

Powyższe polecenia najpierw zwiększają przestrzeń SWAP, następnie formatują ją i aktywują ponownie.

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.

Rozwiązywanie Problemu MySQL – Error_code: 1114


Wprowadzenie

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:

Zmień wartości zmiennej:

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:

Albo


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):

Jeśli problem został rozwiązany, na tym etapie sprawdzenie stanu replikacji:

Nie powinien zwracać żadnych błędów.

Modyfikacja pliku konfiguracyjnego /etc/mysql/my.cnf:

Restart usługi MySQL:

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:

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.

Automatyzacja Procesu Backupu w Proxmox: Praktyczny Skrypt i Konfiguracja Crontab

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:

Ten skrypt wykonuje następujące operacje:

  1. Generuje aktualną datę i czas, które są dodawane do nazwy tworzonego archiwum, aby łatwo można było identyfikować poszczególne kopie.
  2. Używa programu tar z kompresją zstd do stworzenia zarchiwizowanej i skompresowanej kopii katalogu /etc.
  3. 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:

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.

Aktualizowanie Apache Cassandra z wersji 3.1.15 i nowszych do 4.1.x w systemie Ubuntu 20.04.5 LTS: kompleksowy przewodnik

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:

Operacje czyszczenia przed aktualizacją

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:

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:

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.

Zatrzymaj usługę Cassandry:

Zatrzymaj działające usługi Cassandry, aby bezpiecznie przystąpić do aktualizacji:

Aktualizacja Cassandry

Aktualizacja listy źródeł:

Edytuj źródła repozytorium, aby wskazywały na nową wersję Cassandry, dostosowując plik cassandra.sources.list:

Aktualizacja pakietów:

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):

Modyfikacja konfiguracji:

Dostosuj konfigurację Cassandry dla wersji 4.1.x, komentując lub usuwając przestarzałe opcje:

Aktualizacja biblioteki JAMM:

Upewnij się, że biblioteka Java Agent Memory Manager (JAMM) jest zaktualizowana, aby poprawić wydajność:

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.

Optymalizacja i weryfikacja

Optymalizacja wykorzystania pamięci:

Po aktualizacji warto ocenić i zoptymalizować wykorzystanie pamięci i przestrzeni wymiany, aby zapewnić efektywne działanie Cassandry:

Uruchom ponownie usługę Cassandry:

Weryfikacja aktualizacji:

Potwierdź sukces aktualizacji, sprawdzając topologię i stan klastra, upewniając się, że wszystkie węzły są funkcjonalne:

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.):

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.