Klaster OKD (OpenShift) na maszynach wirtualnych Proxmox – Przygotowanie maszyny Storage NFS

Klaster OKD (OpenShift) na maszynach wirtualnych Proxmox

• część 1 https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-przygotowanie-dns/
• część 2 https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-przygotowanie-maszyny-bastion/
• część 3 https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-przygotowanie-maszyny-storage-nfs/
• część 4 https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-uruchomienie-maszyny-bootstrap/
• część 5 https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-uruchomienie-maszyn-control-plane/
• część 6 https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-uruchomienie-maszyn-compute/
• część 7 https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-zakonczenie-instalacji/

Przygotowanie maszyny wirtualnej Storage

Maszyna storage posłuży nam do udostępnienia volumenów lvm o różnym rozmiarze od 1 do 10 GB na potrzeby Persistent Storage naszego klastra OKD (OpenShift). Obraz systemu Fedora Server 41 network install jest do pobrania z tego linku https://download.fedoraproject.org/pub/fedora/linux/releases/41/Server/x86_64/iso/Fedora-Server-netinst-x86_64-41-1.4.iso. Po przegraniu obrazu na isostore Proxmoxa możemy rozpocząć instalację systemu.

Tworzymy nową maszynę wirtualną o id 4020 i nazwie storage z podanymi parametrami:

• Machine : q35, Qemu Agent (włączone)
• 8 GB HDD, SCSI VirtIO Single, Cache: Write Back
• 2 vCPU – 2 x Sockets, Enable NUMA (włączone) , Type: Host
• 2 GB RAM , Balloning Device (włączone)
• Bridge: vmbr4, Model: VirtIO

Przed pierwszym uruchomieniem kopiujemy MAC address maszyny do /etc/dnsmasq.d/vnet na maszynie LXC dnsmasq. Drugi dysk dodamy po zakończonej instalacji systemu.

Wybieramy oczywiście język angielski

Podajemy nazwę hosta: storage.okdlab.local
Ustawiamy statyczny adres ip 192.168.40.20/24, gateway: 192.168.40.1 i dns 192.168.40.10

Ustawiamy hasło dla root-a.

Wybieramy w Software selection: Guest Agent

Klikamy na Click here to crete them automatically. Pozostawiamy schemat partycjonowania na LVM ze względu na łatwą rozszerzalność voluminu i dysku w przyszłości

Wybieramy odpowiedni File System. Fedora rekomenduje dla serwerów XFS.
Można dla wygody i większej czytelności zmienić nazwę Volume Group na vg_fedora a Name volumenu root na lv_root

Brak partycji SWAP

W Fedorze 41 (i podobnych współczesnych wydaniach Fedory) zarządzanie wymianą jest zazwyczaj obsługiwane dynamicznie przy użyciu zram domyślnie. Oto jak zarządzana jest wymiana:

1. Swap oparty na zram
   Fedora używa zram do tworzenia skompresowanego urządzenia blokowego w pamięci dla wymiany.
   Dzięki temu unika się używania dedykowanej partycji wymiany lub pliku na dysku w większości instalacji.
   zram zapewnia lepszą wydajność, ponieważ działa w pamięci i unika wolniejszego wejścia/wyjścia dysku tradycyjnej wymiany.
   Kluczowe cechy:
   Kompresja: Dane przechowywane w zram są kompresowane, co zmniejsza rozmiar pamięci.
   Dynamiczny rozmiar: Rozmiar wymiany zram jest określany na podstawie fizycznego rozmiaru pamięci RAM systemu, często ułamka całkowitej pamięci (np. połowa rozmiaru pamięci RAM).
   Brak zużycia dysków SSD: Ponieważ działa w pamięci RAM, zmniejsza zużycie dysków SSD, które występuje w przypadku tradycyjnych partycji/plików wymiany.
2. Powrót do tradycyjnej wymiany
   Jeśli jawnie utworzysz partycję wymiany lub plik podczas instalacji lub ręcznie ją skonfigurujesz, Fedora użyje jej zamiast zram.
   Fedora obsługuje zarządzanie plikami wymiany lub partycjami za pomocą systemd, używając wpisów w /etc/fstab do trwałej konfiguracji.
3. Konfigurowanie wymiany zram
   Konfiguracja jest zarządzana za pomocą zram-generator, komponentu systemd.

Konfiguracje można znaleźć w /usr/lib/systemd/zram-generator.conf

# tradcyjna konfigfuracja swap
sudo fallocate -l 2G /var/swapfile
sudo chmod 600 /var/swapfile
sudo mkswap /var/swapfile
sudo swapon /var/swapfile
echo '/var/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# wyłączenie swap opartego o zram
sudo systemctl mask [email protected]
sudo swapoff /dev/zram0

Wybór systemu plików XFS czy EXT4

Wybierając między XFS a EXT4 w systemie Fedora, weź pod uwagę następujące czynniki w zależności od przypadku użycia:

1. Wydajność
   XFS:
   Zoptymalizowany pod kątem dużych plików i obciążeń o wysokiej przepustowości, dzięki czemu idealnie nadaje się do serwerów obsługujących multimedia, duże bazy danych lub wirtualizację.
   Doskonały w zarządzaniu równoczesnymi operacjami wejścia/wyjścia i środowiskami o wysokiej wydajności.
   EXT4:
   Wszechstronny system plików o dużej wydajności do użytku na komputerach stacjonarnych lub serwerach ogólnego przeznaczenia.
   Lepsza wydajność w przypadku mniejszych plików i mniej intensywnych obciążeń w porównaniu z XFS.
2. Skalowalność
   XFS:
   Obsługuje większe systemy plików i pliki (do 8 eksabajtów) niż EXT4, dzięki czemu lepiej nadaje się do systemów pamięci masowej przedsiębiorstw lub o dużej pojemności.
   Wydajnie obsługuje duże katalogi i miliony plików.
   EXT4:
   Limit rozmiaru systemu plików wynosi 1 eksabajt, a rozmiar pliku jest ograniczony do 16 terabajtów, co jest wystarczające w większości przypadków użycia.
   Dobrze radzi sobie z małymi i średnimi obciążeniami.
3. Funkcje
   XFS:
   Doskonałe dziennikowanie i zarządzanie metadanymi, co prowadzi do szybszego odzyskiwania w przypadku awarii.
   Umożliwia dynamiczną zmianę rozmiaru, ale tylko rosnących systemów plików (nie obsługuje zmniejszania).
   Zaprojektowany dla integralności danych i wysokiej niezawodności.
   EXT4:
   Obsługuje zmniejszające się i rosnące systemy plików.
   Zawiera funkcje, takie jak opóźniona alokacja i suma kontrolna dziennika, aby zwiększyć niezawodność i zmniejszyć fragmentację.
4. Przypadki użycia
   XFS:
   Serwery o wysokiej wydajności (np. serwery WWW, serwery baz danych).
   Systemy o dużych potrzebach w zakresie pamięci masowej (np. pamięć masowa multimediów, obliczenia naukowe).
   Obciążenia wirtualizacji i kontenerów.
   EXT4:
   Systemy stacjonarne i laptopy.
   Umiarkowane obciążenia, takie jak osobiste przechowywanie plików lub hosting aplikacji.
   Systemy wymagające elastyczności zmiany rozmiaru (zwiększanie i zmniejszanie).
5. Zgodność
   XFS:
   Ograniczona zgodność ze starszymi systemami i systemami operacyjnymi innymi niż Linux.
   EXT4:
   Lepsza zgodność z szerszą gamą systemów, w tym starszymi dystrybucjami Linuksa i narzędziami zewnętrznymi.
6. Narzut i konserwacja
   XFS:
   Może wykorzystywać więcej zasobów procesora do operacji na metadanych.
   Nieco bardziej złożone opcje dostrajania, które mogą wymagać specjalistycznej wiedzy.
   EXT4:
   Ogólnie niższe wykorzystanie procesora.
   Łatwiejsze w konfiguracji i konserwacji, zwłaszcza dla początkujących.

Zalecenie
Wybierz XFS, jeśli:

Używasz serwera o wysokiej wydajności lub pojemności.
Twoje obciążenie obejmuje duże pliki lub wysoką współbieżność.
Wybierz EXT4, jeśli:

Potrzebujesz uniwersalnego systemu plików do codziennego użytku na komputerze stacjonarnym.
Priorytetem jest dla Ciebie elastyczność, kompatybilność i łatwość konserwacji.
Domyślnie Fedora używa XFS dla partycji /, ponieważ jest ona zgodna z nowoczesnymi potrzebami serwerów i przedsiębiorstw. Jednak jeśli budujesz osobistą stację roboczą lub laptopa, EXT4 może być lepszym rozwiązaniem.

Aktualizacja systemu

logujemy się na maszynie storage i przeprowadzamy w razie potrzeby wszelkie administracyjne operacje przez sudo.

sudo dnf update -y

Instalacja przydatnego oprogramowania (do wyboru)

# oprogramowanie użytkowe
sudo dnf install mc git screen wget nano unzip ncdu bzip2 bc vim lynx nmap sshpass -y

Ustawienie konfiguracji sieciowej

Aby poprawnie działało lokalne rozwiązywanie nazw należy wyłączyć split dns usuwając usługę systemd-resolved

sudo systemctl status systemd-resolved
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
# usunąć link
sudo rm /etc/resolv.conf
# utworzyć od nowa
sudo vim /etc/resolv.conf
search okdlab.local
nameserver 192.168.40.10
# restart servera
sudo reboot

Od tej pory to usługa NetworkManager przejmie generowanie /etc/resolv.conf. Jeśli tego nie zrobiliśmy wcześniej to należy również ustawić tutaj statystyczny adres ip używając polecenia.

sudo nmcli connection modify enp6s18 ipv4.addresses 192.168.40.20/24 ipv4.gateway 192.168.40.1 ipv4.dns 192.168.40.10 ipv4.method manual
systemctl restart NetworkManager

Sprawdzenie komunikacji z serwerem DNS dns1.okdlab.local

Przed przystąpieniem do dalszych kroków należy dokładnie sprawdzić rozwiązywanie nazw przez nasz serwer dns1.okdlab.local próbując na różne sposoby odczytać zwracane przez narzędzia dig, nslookup czy ping informacje.

# sprawdzenie konfiguracji DNS
resolvectl
# sprawdzenie działania reverse dns (rekordy PTR)
dig -x 192.168.40.51
# sprawdzenie działania forward dns
nslookup compute-1.testcluster.okdlab.local

Dodanie dysku do maszyny wirtualnej i przygotowanie volumenów LVM

Dodajemy dysk o wybranym przez siebie rozmiarze np. 32 GB do maszyny wirtualnej storage z poziomu konsoli Proxmox

Sprawdzamy czy dysk pojawił się w maszynie wirtualnej. Nie potrzebny jest restart maszyny wirtualnej.

sudo lsblk

Jeśli nowy dysk się pojawił to przystępujemy do jego konfiguracji oraz podziału na volumeny LVM

#inicjalizacja nowego dysku pod LVM czyli utworzenie fizycznego volumenu
sudo pvcreate /dev/sdb
# weryfikacja czy prawidłowo utworzono fizyczny volumen na dysku /dev/sdb
sudo pvdisplay
# utworzenie volume group o nazwie vg_datastore na dysku /dev/sdb, gdzie vg oznacza volume group celem łatwej identyfikacji typu
sudo vgcreate vg_datastore /dev/sdb
# wyświetlenie istniejących grup volumenów
sudo vgdisplay
# utworzenie volumenów lvm o różnym rozmiarze na potrzeby testów klastra i PVC
# np. utworzenie volumenu o nazwie lv_pvc_01 i rozmiarze 1GB w grupie volumenów vg_datastore
sudo lvcreate -n lv_pvc_01 -L 1G vg_datastore
sudo lvcreate -n lv_pvc_02 -L 2G vg_datastore
sudo lvcreate -n lv_pvc_03 -L 3G vg_datastore
sudo lvcreate -n lv_pvc_04 -L 5G vg_datastore
sudo lvcreate -n lv_pvc_05 -L 10G vg_datastore
# wyświetlenie utworzonych volumenów
sudo lvdisplay vg_datastore
# utworzenie systemu plików xfs na utworzonych volumenach
sudo mkfs.xfs /dev/vg_datastore/lv_pvc_01
sudo mkfs.xfs /dev/vg_datastore/lv_pvc_02
sudo mkfs.xfs /dev/vg_datastore/lv_pvc_03
sudo mkfs.xfs /dev/vg_datastore/lv_pvc_04
sudo mkfs.xfs /dev/vg_datastore/lv_pvc_05
# zamontowanie lokalnie utworzonych volumenów lvm
sudo mkdir -p /mnt/lv_pvc_01
sudo mkdir -p /mnt/lv_pvc_02
sudo mkdir -p /mnt/lv_pvc_03
sudo mkdir -p /mnt/lv_pvc_04
sudo mkdir -p /mnt/lv_pvc_05
# sprawdzamy blkid utworzonych volumenów
blkid /dev/vg_datastore/lv_pvc_01
/dev/vg_datastore/lv_pvc_01: UUID="56d538de-1755-468c-886d-b7b2c742e686" BLOCK_SIZE="512" TYPE="xfs"
...
# i dopisujemy je do /etc/fstab
UUID=56d538de-1755-468c-886d-b7b2c742e686 /mnt/lv_pvc_01          xfs     defaults        0 0
...

sudo mount -a
sudo systemctl daemon-reload
# weryfikacja
df -h

Konfigurowanie rejestru obrazów dla klastra OKD (OpenShift)

Rejestr obrazów zostaje usunięty podczas instalacji. Na platformach, które nie zapewniają współdzielonej pamięci masowej obiektów, operator rejestru obrazów OpenShift uruchamia się jako Usunięty. Umożliwia to programowi openshift-installer ukończenie instalacji na tych typach platform. Po instalacji należy edytować konfigurację operatora rejestru obrazów, aby zmienić stan zarządzania z Usuniętego na Zarządzany. Po zakończeniu tej czynności należy skonfigurować pamięć masową. Więcej informacji można znaleźć tutaj https://docs.openshift.com/container-platform/4.15/registry/configuring_registry_storage/configuring-registry-storage-baremetal.html. Na konsoli Proxmox na naszym serwerze NFS dodajemy nowy dysk o rozmiarze 100 GB (jak w przykładzie poniżej) albo rozszerzamy istniejący /dev/sdb i tworzymy volumen o nazwie lv_pv_registry

# sprawdzamy czy pojawił się dysk /dev/sdc 
sudo lsblk
# tworzymy fizyczny volumen na dysku
sudo pvcreate /dev/sdc
 # tworzymy grupę volumenów o nazwie vg_registry
sudo vgcreate vg_registry /dev/sdc
 # tworzymy volumen o nazwie 
sudo lvcreate -n lv_registry -l 100%FREE vg_registry
# tworzymy system plików XFS na volumenie
sudo mkfs.xfs /dev/vg_registry/lv_registry
 # tworzymy punkt montowania
sudo mkdir /mnt/lv_registry
 # sprawdwzamy id urzadzenia blokowego
 sudo blkid /dev/vg_registry/lv_registry
/dev/vg_registry/lv_registry: UUID="e7d5ce21-4c29-42c4-907f-4351db14aa9a" BLOCK_SIZE="512" TYPE="xfs"
# dodajemy wpis do /etc/fstab
sudo nano /etc/fstab
...
UUID=e7d5ce21-4c29-42c4-907f-4351db14aa9a /mnt/lv_registry        xfs     defaults        0 0
# odświeżamy punkty montowania
sudo mount -a
sudo systemctl daemon-reload
# dodajemy udostępnienie w konfiguracji serwera NFS
sudo nano /etc/exports
...
/mnt/lv_registry 192.168.40.0/24(rw,sync,no_root_squash,no_subtree_check)
# restart serwera NFS
sudo systemctl restart nfs-server
# nadanie odpowiednich uprawnien
sudo chown -R nobody:nobody /mnt/lv_registry/
sudo chmod -R 777 /mnt/lv_registry/

Zmiana rozmiaru dysku systemowego opartego na LVM

#sprawdzamy zajętość głównego systemu pliku
df -h /
# sprawdzamy dostępne miejsce w grupie volumenów o nawie fedora
vgdisplay fedora

zwiększamy w konsoli Proxmox rozmiar dysku z 8GB na 12GB, dodając 4 GB. Nie musimy uruchamiać maszyny ponownie.

# sprawdzamy czy dysk jest powiekszony
lsblk
# rozszerzamy dysk
parted /dev/sda
resizepart 3
100%
quit

sudo partprobe
sudo pvresize /dev/sda3
sudo lvextend /dev/fedora/root -l+100%FREE
sudo xfs_growfs /dev/fedora/root

Instalacja servera NFS

sudo dnf install nfs-utils
# automatyczne uruchomienie usługi nfs po starcie
sudo systemctl enable nfs-server --now
# sprawdzenie stanu usługi nfs
sudo systemctl status nfs-server
# sprawdzenie wersji obsługiwanych protokołu nfs
cat /proc/fs/nfsd/versions

Zezwolenie na ruch na firewallu oraz ustawienia środowiska SELinux

sudo firewall-cmd --permanent --add-service=nfs
sudo firewall-cmd --permanent --add-service=mountd
sudo firewall-cmd --permanent --add-service=rpc-bind
sudo firewall-cmd --reload

# jeśli mamy włączony SELinux to dodatkowo
sudo setsebool -P nfs_export_all_rw 1

# jeśli nie potrzebujemy SELinux
sudo sudo sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
sudo reboot

Konfiguracja udostępnianych zasobów przez server NFS

Edytujemy plik /etc/exports

/mnt/lv_pvc_01 192.168.40.0/24(rw,sync,no_root_squash,no_all_squash,no_wdelay)
/mnt/lv_pvc_02 192.168.40.0/24(rw,sync,no_root_squash,no_all_squash,no_wdelay)
/mnt/lv_pvc_03 192.168.40.0/24(rw,sync,no_root_squash,no_all_squash,no_wdelay)
/mnt/lv_pvc_04 192.168.40.0/24(rw,sync,no_root_squash,no_all_squash,no_wdelay)
/mnt/lv_pvc_05 192.168.40.0/24(rw,sync,no_root_squash,no_all_squash,no_wdelay)

Restartujemy usługę nfs-server i sprawdzamy istniejące udostępnienia

sudo systemctl restart nfs-server
showmount -e localhost

Weryfikacja działania servera NFS z maszyny bastion

Wstępnie weryfikujemy czy udostępnione dyski LVM są dostępne dla innych maszyn w sieci okd np. na maszynie bastion.

sudo mkdir -p /mnt/lv_pvc_01
sudo mount -t nfs 192.168.40.20:/mnt/lv_pvc_01 /mnt/lv_pvc_01/
sudo df -h /mnt/lv_pvc_01
sudo touch /mnt/lv_pvc_01/test.txt

Maszyna storage jest teraz gotowa do serwowania udziałów lvm potrzebnych dla Persistent Storage naszego klastra OKD (OpensShift).