Pl:Serwer polskiej społeczności

Dyski

Dokumentacja:

• https://sites.google.com/a/chroot.ru/notes/storages/add-drive-to-lsi-raid-volume
• https://raid.wiki.kernel.org/index.php/Hardware_Raid_Setup_using_MegaCli
• https://help.serversaustralia.com.au/s/article/megacli-megacli64-cheatsheet

megaclisas-status - ogólny stan dysków

-a0 - adapter 0 (jedyny w tym systemie)

-L3 - 3 wirtualny dysk

Przykłady poleceń:

Diagnostyka i informacje

• Stan 3 wirtualnego dysku
  • megacli -LDInfo -L3 -a0
• Stan wszystkich dysków fizycznych
  • megacli -PDList -aALL

Dodawanie wirtualnych dysków

• Dodanie RAID-1 na 2 dyski SSD (1 TB Evo 870):
  • megacli -CfgLdAdd -r1 [31:4,31:5] WB Direct -a0
• Dodanie RAID-0 na 1 dysk SSD (120 GB):
  • megacli -CfgLdAdd -r0 [31:3] WB Direct -a0

Usuwanie wirtualnych dysków

• Usuwanie wirtualnego dysku 4 (RAID-0 na 1 dysk SSD 120 GB):
  • megacli -CfgLdDel -L4 -a0

Dodawanie brakującego dysku do macierzy

• Wstawienie do macierzy x na pozycji y (uwaga: to nie zwykły numer macierzy - The number N of the array parameter is the Span Reference you get using "MegaCli -CfgDsply -aALLâ€� and the number N of the row parameter is the Physical Disk in that span or array starting with zero (it’s not the physical disk’s slot!.") nieużywanego dysku (ważna jest kolejność parametrów!):
  • megacli -PdReplaceMissing -PhysDrv[31:0] -ArrayX -rowY -a0

Tworzenie i konfigurowanie BTRFS

Istnieją co najmniej 2 możliwości na konfigurację BTRFS razem z LXD:

Półautomatycznie z użyciem LXD:

• Polecenie tworzy filesystem i storage: lxc storage create lxd-ssd-pool btrfs source=/dev/disk/by-id/wwn-<dalsze id>:
• W przypadku błędu jeśli dysk nie był czysty, polecenie zwróci błąd. Taki dysk można wyczyścić: wipefs -a /dev/disk/by-id/<id dysku> UWAGA! TO POWODUJE UTRATĘ DANYCH Z DYSKU!
• Po dodawaniu puli przez LXC prawdopodobnie storage z LXC jak i sam sam filesystem będą miały tą samą nazwę. Można zmienić etykietę dla BTRFS (choć to jest niepewne – z tym coś bywa nie tak i te nazwy się resetują): btrfs filesystem label /dev/disk/by-id/wwn-<id dysku> <nowa nazwa>

Manualnie (rekomendowane) – zamontować trwale, a następnie zlinkować do LXD:

• Utworzenie filesystemu: mkfs.btrfs -f -L btrfs-ssd-pool /dev/disk/by-id/wwn-<dalsze id>
• Edycja /etc/fstab/ i odpowiednie utworzenie folderu pod mountpoint: UUID=1e85ac28-1389-4285-b354-faff04159314 /btrfs-tomczk-pool btrfs compress=zstd:10 0 0, gdzie w tym przypadku:
  • UUID to identyfikator filesystemu BTRFS. Widoczny pod btrfs filesystem show
  • /btrfs-tomczk-pool to miejsce montowania dysku – NIEZMIENIALNE – inaczej to powoduje problemy w LXD. Katalog musi istnieć na dysku.
  • btrfs – filesystem
  • compress=zstd:10 0 0 – dodatkowe parametry, tu akurat wybrany algorytm kompresji zstd o sile 10 na 15
• Aby sprawdzić poprawność edytowanego pliku fstab można wykonać mount -fav – komenda próbuje zamontować wszystko zgodnie z plikiem a parametr "f" oznacza "fake", więc zmiany są symulowane. Warto to zrobić potem bez "f" przed montowaniem do LXD (inną opcja jest np. reboot).
• Następnie trzeba zlinkować nowy storage z LXD. Komenda jest taka jak w przypadku półautomatycznego z tą różnicą, że w source podajemy trwałą podmontowaną ścieżkę – w tym przypadku /btrfs-tomczk-pool lxc storage create lxd-tomczk-pool btrfs source=/btrfs-tomczk-pool. Nazwy inne w celu rozróżnienia tego co jest, a nie jest bezpośrednio zarządzane przez LXD.

Czyszczenie i utrzymanie BTRFS

Wadą BTRFS jest to, że lubi sztucznie zapełniać miejsce, mimo jego braku wykorzystania. Ma to miejsce np. w przypadku puli dockerowej. BTRFS ma możliwość sprzątania. Polecenie btrfs balance <path> zwalnia sztucznie zajęte miejsce, aby to zrobić BTRFS musi być zamontowany w systemie. UWAGA przy większym dysku może to długo potrwać. Status wykonywania można zobaczyć w 2 sesji wpisując btrfs balance status -v <path>.

Usuwanie BTRFS

UWAGA ta sekcja może spowodować utratę danych. Ostrożnie!

Jeśli BTRFS był wykorzystywany przez jakiekolwiek oprogramowanie np. LXD, to warto najpierw je stamtąd odłączyć. Można to zrobić poprzez lxc storage delete <nazwa storage>

Następnie można po prostu wyczyścić dysk (o ile BTRFS był na dysku, a nie plikowy) używając wipefs -a /dev/disk/by-id/<id dysku>. Warto pamiętać o usunięciu wpisu z /etc/fstab o ile taki tam był.

Tworzenie i konfiguracja przestrzeni dla całej planety do kafelków pod ZFS:

• Pula na wirtualny dysk 2x 1 TB Samsung Evo 870 SSD (/dev/sdc):
  • zpool create zfs-ssd /dev/disk/by-id/wwn-0x600605b004f93110284b3fccfae37e03
• System plików dla bazy i kafelków (nie pozwala kaskadowo zrobić końcowego):
  • zfs create zfs-ssd/containers
  • zfs create zfs-ssd/containers/c50-tiles
  • zfs create zfs-ssd/containers/c50-tiles/data

Z powodu wielkiej ilości danych prawdopodobnie wszystko pójdzie dla serwera kafelków, więc wszystkie opcje są dopasowane do ich potrzeb i ustawiamy opcje dla całej puli, a nie dla systemu plików:

• Czas dostępu jest zbędny dla bazy danych - wydłuża czas i zużywa nośnik:
  • zfs set atime=off zfs-ssd
• Kompresja LZ4 niezbędna, żeby udało się zrobić import planety na 1 TB:
  • zfs set compression=lz4 zfs-ssd
• Rozmiar rekordu polecany dla PostgreSQL:
  • zfs set recordsize=8K zfs-ssd
• Opcja polecana dla PostgreSQL:
  • zfs set logbias=throughput zfs-ssd

Podłączenie systemu plików kafelkowych danych pod kontener LXC:

• Montowanie w miejscu widoczny przez LXC
  • zfs set mountpoint=/var/lib/lxd/storage-pools/zfs-ssd-pool/containers/c50-tiles/data zfs-ssd/containers/c50-tiles/data
• Montowanie w kontenerze c50-tiles:
  • lxc config device add c50-tiles ssd-data disk source=/var/lib/lxd/storage-pools/zfs-ssd-pool/containers/c50-tiles/data path=/media/data

Usuwanie przestrzeni dla całej planety

Najpierw wyprzęgamy z LXC:

• lxc config device remove c50-tiles ssd-data

Potem wywalamy z poziomu ZFS (o ile nie ma oczywiście innych kontenerów które z tego korzystają) - pewnie wystarczy hurtem, zamiast po kolei każdy podkatalog:

• zfs destroy zfs-ssd/containers

budynki.openstreetmap.org.pl

Repozytorium GitHub: https://github.com/openstreetmap-polska/gugik2osm

W kontenerze większość jest w lokalizacji /opt/gugik2osm/

Opis ścieżek:

• /opt/gugik2osm/
  • log - logi aplikacji i procesów przetwarzających dane
  • git - sklonowane repo z githuba
  • app - backend Pythonowy
  • web - frontend HTML+CSS+JS
  • venv - wirtualne środowisko Python z zainstalowanymi bibliotekami
  • imposm3 - folder z danymi programu imposm3, który importuje dane z OSM do bazy PostgreSQL
  • temp* - foldery na dane tymczasowe: pliki PRG, BDOT, etc.
  • conf - pliki konfiguracyjne, pomocne skrypty Bash etc.
• /var/www/
  • html - symlink do folderu web wspomnianego powyżej
  • data - dodatkowe dane, które użytkownicy mogą pobierać z serwera np pliki geopackage z budynkami z BDOT itp są tam też backupy bazy danych (wystawiane publicznie, bo w tej bazie nie ma nic co nie było by publiczne)
  • overpass-layers - pliki geojson z danymi z Overpass, które można wyświetlić na mapie na stronie

W folderze /opt/gugik2osm/conf/ jest trochę plików które się przydają przy administracji serwerem:

• cronfile - plik podlinkowany do CRONa, pełna lista odpalanych rzeczy razem ze schedule
• deploy.sh - plik pobiera zmiany z github i wrzuca je do katalogów dla backendu i frontendu na serwerze. Załatwia to deployowania prostych zmian. Jeżeli coś wymaga zmian w bazie danych to nie ma automatycznych migracji i wymaga to dodatkowych akcji użytkownika. Ten plik jest odpalany też z CICD Githuba w przypadku dodania do repo Release.
• deploy_*_mappings.sh - pliki pozwalające szybko wrzucić od bazy zawartość plików CSV z mapowaniem pewnych kategorii/nazw (nazwy ulic, kategorie BDOT)
• maintenance_mode_on/off.sh - skrypty włączające tyb "maintenance", czyli strona zostaje zastąpiona prostym HTMLem "Trwają prace konserwacyjne" plus odznaczenie flagi w bazie danych, która powinna blokować requesty z backendu
• services_restart.sh - restartuje serwisy postgresa, imposma, supervisora (gunicorna)

Import danych imposm3 w przypadku gdy chcemy dograć nowe tabelki albo coś:

Aktualizacja postgresa do nowej głównej wersji (np 13->14):

1. sudo apt upgrade - powinno pobrać samego postgresa kiedy będzie dostępny
2. sudo apt install postgresql-14-postgis-3 - doinstalowanie nowego postgisa
3. sudo service imposm stop - zatrzymanie programu imposm3
4. dobrze też zakomentować w cronfile żeby rzeczy nie chodziły co minutę
5. sudo -u postgres pg_upgradecluster 13 main - upgrade serwera

c10-http-proxy

Kontener zawiera reverse http proxy, które terminuje SSL i przekierowuje ruch do odpowiednich podstron w innych kontenerach.

Odpowiada za certyfikaty SSL Let's Encrypt. Program certbot pozwala dodawać i odnawiać certyfikaty.

Listowanie certyfikatów: certbot certificates

Procedura tworzenia nowego kontenera

Nazwy kontenerów pochodzą od adresów IP oraz serwisów, które serwują. Adresy IP nadawane są indywidualnie, uznaniowo, staramy się aby poszczególne dziesiątki odpowiadały różnym grupą serwisów.

Procedura na przykładzie kontenera c24-aed-osm-org-pl

1. Utworzenie nowego kontenera launch ubuntu:20.04 c24-aed-osm-org-pl.
2. Kopiujemy konfigurację IP z istniejącego kontenera, np c10-http-proxy: lxc exec c10-http-proxy -- cat /etc/netplan/51-cloud-init.yaml. Kopiujemy konfigurację do schowka.
3. Ustawienie adresu IP w kontenerze: lxc exec c24-aed-osm-org-pl -- nano /etc/netplan/51-cloud-init.yaml. Wstawiamy konfigurację i poprawiamy adres IP na nowy – w tym przypadku: 10.11.12.24. Zapisujemy i restartujemy kontener: lxc restart c24-aed-osm-org-pl. Poleceniem lxc list można sprawdzić, czy kontener używa ustawionego przez nas adresu IP, jeśli nie, to prawdopodobnie jest błąd w pliku (należy pamiętać, o odpowiednich wcięciach).
4. Aktualizacja kontenera i instalacja potrzebnych pakietów: Wchodzimy do kontenera: lxc shell c24-aed-osm-org-pl, a następnie: apt update && apt upgrade -y && apt install -y nginx. Kontener jest gotowy – wychodzimy ctrl+d.
5. W kolejnych krokach ustawiamy przekierowanie http w kontenerze z proxy: lxc shell c10-http-proxy
   1. Kopiujemy jakąś istniejącą konfigurację virtualhost-a: cd /etc/nginx/sites-available && cp garmin.osmapa.pl.config aed.openstreetmap.org.pl.config.
   2. W konfiguracji zmieniamy wszystkie wystąpienia starej domeny na nową (tak, wszystkie, te w ścieżkach też).
   3. W sekcji z przekierowaniem ustawiamy adres IP nowo utworzonego kontenera.
   4. Komentujemy tymczasowo całą sekcję dotyczącą https, żeby móc utworzyć certyfikat.
   5. Przed wyjściem kopiujemy do schowka ścieżkę do webroot-a nowego vhosta, zapisujemy config i wychodzimy.
   6. Tworzymy webroot i zmieniamy mu właściciela: mkdir -p /srv/www/aed.openstreetmap.org.pl/public && chown -R www-data:www-data /srv/www.
   7. Linkujemy nową konfigurację i restartujemy nginx: cd ../sites-enabled/ && ln -s ../sites-available/aed.openstreetmap.org.pl.config ., a następnie: service nginx reload.
   8. Wykonujemy próbę pobrania certyfikatu dla nowej domeny:
      1. Dla 1 domeny: certbot certonly --webroot -w /srv/www/aed.openstreetmap.org.pl/public/ -d aed.openstreetmap.org.pl --dry-run
      2. Dla 2+ domen (np. prod i dev): certbot certonly --cert-name aed.openstreetmap.org.pl -a webroot -w /srv/www/aed.openstreetmap.org.pl/public/ -d aed.openstreetmap.org.pl,aed-dev.openstreetmap.org.pl --dry-run
   9. Jeśli próba przebiegnie prawidłowo (IMPORTANT NOTES:- The dry run was successful.) uruchamiamy jeszcze raz, tym razem bez --dry-run: certbot certonly --webroot -w /srv/www/aed.openstreetmap.org.pl/public/ -d aed.openstreetmap.org.pl.
   10. Poleceniem certbot renew --cert-name aed.openstreetmap.org.pl --dry-run możemy sprawdzić, czy certyfikat sam się poprawnie odnowi (przy końcu terminu ważności).
   11. Edytujemy config strony i odkomentowujemy sekcję odpowiedzialną za https.
   12. Restartujemy nginx.

Na tym etapie wszystko powinno już działać prawidłowo. Wchodząc przeglądarką na nowy adres powinniśmy dostać stronę startową nowego serwisu zabezpieczoną po https

Żeby do kontenera można było logować się przez SSH należy dodać użytkownika w kontenerze, dodać mu klucz publiczny SSH oraz na poziomie hosta skonfigurować reguły firehol.

Jeśli to jest nowy projekt publiczny, dodaj go do spisu usług na tej stronie wiki i na stronie polskiej społeczności!

# demo == nazwa naszego kontenera LXC
lxc storage create docker btrfs  # To należy pominąć jeśli już istnieje
lxc storage volume create docker demo
lxc launch images:ubuntu/20.04 demo  # To również należy pominąć jeśli kontener już istnieje
lxc config device add demo docker disk pool=docker source=demo path=/var/lib/docker
lxc config set demo security.nesting=true security.syscalls.intercept.setxattr=true security.syscalls.intercept.mknod=true
lxc restart demo