Pe propria piele am decis sa testez versiunea gratuita a lui Cloudflare. Doream un loc unde sa hostez dns-ul pentru ill.ro, am zis ca las pe locul 2 afraid.org pentru moment. Avantajele unui cont gratuit Cloudflare pentru mine ar fi – zona unde sa tin DNS-ul si mai mult decat atat https gratuit – aveam si inainte pe LetsEncrypt dar am zis sa incerc si Cloudflare.

Daca iti hostezi blogul acasa, expunerea acestuia direct pe internet vine cu riscuri de securitate. Folosind un cont gratuit Cloudflare pentru gestionarea DNS-ului si protejarea traficului, poti obtine beneficii semnificative atat in ceea ce priveste securitatea, cat si performanta site-ului tau.

1. Securitate sporita prin filtrarea traficului

Cloudflare functioneaza ca un proxy intre vizitatori si serverul tau, ceea ce inseamna ca atacurile directe asupra IP-ului tau real sunt mult mai dificil de realizat. Unul dintre cele mai mari avantaje este posibilitatea de a configura firewall-ul astfel incat sa permita accesul pe portul 443 doar de la IP-urile Cloudflare.

Cum functioneaza?

  • Cloudflare ofera o lista de IP-uri pe care le poti folosi pentru a permite accesul doar de la infrastructura lor. Lista actualizata de IP-uri Cloudflare poate fi gasita aici: Cloudflare IP Ranges.
  • In pfSense/omada sau orice alt firewall, poti configura reguli pentru a bloca accesul direct din internet pe portul 443 si sa permiti doar IP-urile Cloudflare.
  • Acest lucru inseamna ca atacurile automate sau scanarile de porturi nu vor ajunge la serverul tau, deoarece doar traficul proxy Cloudflare este acceptat.

2. Protectie impotriva atacurilor DDoS

Cloudflare include in planul gratuit protectie de baza impotriva atacurilor DDoS, filtrand cererile malitioase si blocand traficul suspect. Acest lucru este esential daca hostezi un blog de acasa, deoarece conexiunea ta nu are latimea de banda necesara pentru a sustine un atac de amploare (1GB de la RDS poate fi suficient, dar sigur nu ai infrastructura sa treci printr-un DDoS.

3. Cache si imbunatatirea performantelor

Cloudflare poate prelua o parte din continutul static al site-ului tau (imagini, CSS, JavaScript) si sa il serveasca direct din reteaua lor globala, reducand astfel incarcarea pe serverul tau. Acest lucru duce la:

  • Timp de incarcare mai rapid pentru vizitatori
  • Consum mai redus de resurse pe serverul tau
  • Mai putina latime de banda utilizata pe conexiunea ta de internet

4. Certificat SSL gratuit

Activand Cloudflare, poti obtine un certificat SSL gratuit si sa iti securizezi conexiunea HTTPS fara a fi nevoie sa instalezi si sa reinnoiesti manual certificate pe serverul tau – asta mie imi pare un mare avantaj ca mi-a expirat de cateva ori certificatul de la LetsEncrypt ca nu aveam portul corect expus. Dar daca dadea eroarea aia de certificat…. se supara cineva? :))

5. Ascunderea IP-ului real al serverului

Atunci cand folosesti Cloudflare, adresa IP a serverului tau ramane ascunsa, ceea ce inseamna ca un atacator nu poate identifica cu usurinta unde este hostat blogul tau. Acest lucru iti protejeaza infrastructura si reduce sansele unor atacuri tintite.

6. Protectia altor tipuri de site-uri

Pe langa un blog personal, poti folosi Cloudflare pentru a proteja orice tip de site, inclusiv site-ul companiei tale. Indiferent daca hostezi un magazin online sau un portal de servicii, avantajele Cloudflare se aplica si aici, oferind securitate si performanta sporita.

7. Beneficiile unui plan platit

Daca decizi sa cumperi macar cea mai basic subscriptie Cloudflare, vei avea acces la functii avansate precum:

  • Load Balancing – distribuirea traficului intre mai multe servere pentru a imbunatati disponibilitatea si performanta.
  • WAF (Web Application Firewall) – protejarea aplicatiilor web impotriva atacurilor comune, cum ar fi SQL injection si XSS.
  • Prioritizare la mitigarea atacurilor DDoS – protectie imbunatatita impotriva atacurilor mai sofisticate.
  • Reguli personalizate pentru firewall – control mai granular asupra traficului si atacurilor blocate.
  • Analize detaliate despre trafic – acces la rapoarte avansate despre cine acceseaza site-ul tau si potentiale amenintari.

Concluzie

Folosind un cont gratuit Cloudflare, poti imbunatati semnificativ securitatea blogului tau hostat acasa, protejandu-l impotriva atacurilor, ascunzand IP-ul real si filtrand traficul. Configurarea firewall-ului pentru a permite acces doar de la IP-urile Cloudflare este un pas esential pentru securizare si reducerea riscurilor. Daca hostezi un site pe infrastructura proprie, integrarea cu Cloudflare este una dintre cele mai simple si eficiente metode de protectie. In plus, un plan platit aduce si mai multe beneficii pentru o securitate si performanta superioara.

In Cloud e simplu, cu toate ca servicii asemanatoare cloudflare se puteau tine acasa sub alte forme / solutii cred ca asta e cea mai rapida metoda, in doar cativa pasi, prin care poti sa te protejezi un pic.

La munca am tot auzit de Helm și Helm Charts. Termeni care înseamnă ceva gen „instalează x și y cu Helm” sau „upgrade cu Helm Charts”. Deci, ce naiba sunt Helm și Charts?

Pe scurt, Helm este un manager de pachete pentru Kubernetes, iar Helm Charts sunt ca niște rețete. Aceste rețete sunt folosite pentru a instala și gestiona aplicații în Kubernetes. Imaginează-ți că ai nevoie de o aplicație care include mai multe componente (poduri, servicii, deployment-uri etc.). Un Helm Chart îți permite să definești toate aceste componente într-un mod standardizat.

Helm este pentru Kubernetes ceea ce apt este pentru Debian: un tool care îți simplifică viața. Iar pe Artifact Hub (https://artifacthub.io/) găsești peste 16.000 de „rețete” pentru tot felul de aplicații. Bineînțeles, îți poți face și tu propriile Charts dacă ai nevoie de ceva mai customizat.

Pentru ca am vazut Kubernetes Dashboard si pentru ca arata bine, si pare asa… ca daca ai K8S Dashboard sigur te pricepi am zis sa invat cum se instaleaza. Prima optiune – cu Helm!

Instalarea Kubernetes Dashboard cu Helm

Hai să vedem cum putem folosi Helm pentru a instala Kubernetes Dashboard.

Pasul 1: Instalarea Helm pe controller-ul Kubernetes

Mai întâi, instalezi Helm. Este simplu, doar urmezi aceste comenzi, care o sa downloadeze un script, dupa care il faci executabil si il … executi. Headshot!

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh

Pasul 2: Adăugarea repository-ului pentru Kubernetes Dashboard

Acum adăugăm repository-ul unde este disponibil Kubernetes Dashboard:

$ helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
$ helm repo list

Pasul 3: Instalarea Kubernetes Dashboard

Instalăm Dashboard-ul folosind comanda:

$ helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard \
    --create-namespace --namespace kubernetes-dashboard

Această comandă:

  • Instalează (sau face upgrade dacă e deja instalat) Kubernetes Dashboard.
  • Creează namespace-ul kubernetes-dashboard dacă nu există.

Pasul 4: Publicarea Dashboard-ului

Pentru a accesa Dashboard-ul, îl publicăm pe un port:

$ kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard-kong-proxy 8443:443
$ kubectl -n kubernetes-dashboard get svc

Acum, accesează Kubernetes Dashboard la adresa: https://localhost:8443. Cumva e inutil, ca nimeni nu are un nodurile instalate cu KDE/Gnome si deschid de acolo un firefox ca sa acceseze servicii. Cel mult un curl, un wget… Dar… se poate publica pe ip-ul nodului… ceea ce e mai ok, il poti accesa din afara kubernetzilor.

$ kubectl get svc kubernetes-dashboard-kong-proxy -n kubernetes-dashboard -o yaml > kong-service.yaml

$ nano kong-service.yaml - editam sectiunea spec:
spec:
  type: NodePort
  ports:
  - name: kong-proxy-tls
    port: 443
    protocol: TCP
    targetPort: 8443
    nodePort: 32444
$ kubectl apply -f kong-service.yaml

Acum kong-proxy este expus pe ip-urile nodurilor, pe portul selectat manual de noi, 32444. Nu e optim sa specifici tu porturi… dar avem acces la dashboard.

$ nano cont-dasboard.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
name: admin-user
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-user
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: admin-user
namespace: kube-system

Acum aplicam yaml-ul (o sa faca userul si il pune unde ii este locul) – totul e specificat in yaml.
Avem user si acum ii facem un token. Copy paste in browser la https://ip_nod:8443, acolo unde ne cere.

$ kubectl create -f cont-dashboard.yaml
serviceaccount/admin-user created
clusterrolebinding.rbac.authorization.k8s.io/admin-user created

$ kubectl -n kube-system create token admin-user

Rezultate:

Avem kubernetes-dashboard, am facut un printscreen si l-am aratat prietenilor. O sa ramana aici pentru posteritate, ii gasesc o utilitate cand o sa am mai multe chestii pe k8s. Deocamdata e bun exercitiul ca am folosit helm sa-l deployes, am invatat sa il public pe noduri… si am facut si un user/token ca sa il putem accesa. Minunat!
Ce ar fi interesant, ceva sa expunem serviciul mai usor, metode sunt si chiar există mai multe metode prin care serviciile dintr-un cluster Kubernetes pot fi expuse utilizatorilor finali:

Ingress Controller: Utilizează un controller pentru a gestiona cererile HTTP și HTTPS, oferind un mod flexibil și scalabil de a expune mai multe servicii printr-un singur punct de intrare. Exemple populare includ Nginx Ingress Controller și Traefik.

LoadBalancer: Creează un load balancer extern care distribuie traficul către serviciul din cluster. Exemple includ soluții oferite de cloud providers, cum ar fi AWS Elastic Load Balancer (ELB), Google Cloud Load Balancer (GCLB) și Azure Load Balancer.
On prem poti folosi HA Proxy si Metal ILB

NodePort: Deschide un port specific pe fiecare nod al clusterului, permițând accesul extern. Pe acesta l-am utilizat si pot spune ca pe termen lung nu il vad ca winning sollution dar e foarte rapid sa vezi un serviciu din kube…

Asta cred ca ne indica deja ce o sa incerc next. Primele 2 coloane de mai sus sunt tema :))

Sa punem chihuahua-urile (cele 3 lenovo M710q si M715q) la munca. Pe langa plex, qbittorrent, NFS si ce mai hosteaza ei pentru “home” vreau sa continui cu “learning path-ul”. Vor trebui sa hosteze un cluster de Kubernetes 1.32 pe care sa-mi fac eu mendrele. As vrea sa fac o copie a blogului asta… si sa o hostez acolo, in paralel cu asta. Pana acolo-i mult de munca asa ca incep cu ISO-ul cel mai recent de debian si fac 3VM-uri.

Am ajuns la momentul mult așteptat (de mine): avem un cluster de 3 servere Linux, bazate pe Debian. Dacă sunteți aici, presupun că știți deja să instalați un sistem de operare, așa că să trecem direct la configurație.

Configurație de bază

Am alocat resursele următoare pentru fiecare nod, iar rețeaua este configurată în 10.0.0.0/24. DHCP-ul a fost generos și a oferit următoarele IP-uri:

  • k8s-control: 4vCPU, 8GB RAM, 20GB stocare (IP: 10.0.0.27)
  • k8s-worker1: 4vCPU, 8GB RAM, 20GB stocare (IP: 10.0.0.28)
  • k8s-worker2: 4vCPU, 8GB RAM, 20GB stocare (IP: 10.0.0.29)

Teoretic, resursele pot fi reduse (de exemplu, 2vCPU și 4GB RAM), dar recomand să alocați mai mult pentru a evita problemele legate de pod-uri care nu pornesc din lipsă de resurse.

Editarea fișierului /etc/hosts

Pe toate nodurile, adăugăm următoarele intrări pentru a asigura rezolvarea corectă a numelor:

10.0.0.27   k8s-control.ill.lan   k8s-control
10.0.0.28   k8s-worker1.ill.lan   k8s-worker1
10.0.0.29   k8s-worker2.ill.lan   k8s-worker2

Dezactivăm Swap

Pentru că kubelet și swap-ul nu sunt prieteni:

swapoff -a
sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

Configurăm kernel-ul pentru Kubernetes

Asigurăm că modulul kernel-ului este pregătit:

cat <<EOF | tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF

$ modprobe overlay
$ modprobe br_netfilter

cat <<EOF | tee /etc/sysctl.d/99-kubernetes-k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

$ sysctl --system

Instalarea containerd

$ apt update
$ apt -y install containerd

Modificăm configurația pentru a activa SystemdCgroup:

$ containerd config default | tee /etc/containerd/config.toml >/dev/null 2>&1
nano /etc/containerd/config.toml

Căutați secțiunea [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] și schimbați SystemdCgroup = false în SystemdCgroup = true.

Repornim serviciul:

$ systemctl restart containerd && systemctl enable containerd

Adăugăm repo-ul Kubernetes

$ echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.32/deb/ /" | sudo tee /etc/apt/sources.list.d/kubernetes.list
$ curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.32/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

Instalăm uneltele Kubernetes

$ apt update
$ apt install kubelet kubeadm kubectl -y
$ apt-mark hold kubelet kubeadm kubectl

Inițializarea cluster-ului Kubernetes

Ultimul pas important, parerea mea, boot-strap-on clusterului. Incepem usor si creăm un fișier kubelet.yaml:

apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: "1.32.0"
controlPlaneEndpoint: "k8s-control"
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration

Rulăm comanda:

kubeadm init --config kubelet.yaml

Configurăm accesul pentru utilizatorul non-root (se ruleaza din userul din care planuiti sa folositi kubectl:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Testăm cluster-ul (din root sau userul non-root):

kubectl get nodes
kubectl cluster-info

Ar trebui să vedem control plane-ul activ. Pentru a adăuga noduri, folosim comanda kubeadm join generată automat la finalul output-ului lui kubeadm init:

kubeadm join k8s-control:6443 --token TOKEN --discovery-token-ca-cert-hash SHA256

Alegerea și instalarea unui CNI

Kubernetes nu instalează by default niciun CNI (Container Network Interface) deoarece este compatibil cu prea multe opțiuni și lasă alegerea la latitudinea utilizatorului. Alegerea unui CNI depinde de nevoile rețelelor și de experiența utilizatorului.

Opțiuni populare pentru CNI și nivelul de dificultate:

  1. Flannel (ușor): Simplu de instalat și configurat, perfect pentru homelab-uri. Are performanțe decente pentru rețele simple.
    Instrucțiuni de instalare
  2. Calico (mediu): Ideal pentru cei care vor funcționalități suplimentare precum Network Policies. Este ușor de folosit în homelab-uri cu nevoi moderate.
    Instrucțiuni de instalare
  3. Cilium (avansat): Alegerea potrivită pentru cei care doresc performanță ridicată, securitate avansată și integrare cu eBPF. Recomandat pentru homelab-uri avansate.
    Instrucțiuni de instalare

Exemplu de instalare Cilium:

Pare complex?

helm repo add cilium https://helm.cilium.io/
helm repo update
helm install cilium cilium/cilium --version 1.14.0 \
    --namespace kube-system \
    --set kubeProxyReplacement=partial \
    --set k8sServiceHost=k8s-control \
    --set k8sServicePort=6443

Ce am instalat eu? Calico. Pentru ca imi plac pisicile. Nu am avut alt motiv… e mediu de complex si ca e simplu de instalat.

Exemplu de instalare Calico.

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml

Proxmox din titlu este inutil. Putea fi foarte bine si HyperV, Vmware Workstation… Probabil pentru scopul de a invata as fi putut sa aleg si ceva mai usor, k3s, minikube… etc. Acum ca am un cluster de Kubernetes va trebui sa invat sa il folosesc, ca e ca acu 25 de ani cand am instalat primul meu linux… si acum ce fac? :))
Am calico, am toate componentele


Tema finala e wordpress in kubernetz… cu toate ca am impresia ca nu e nevoie sa complici atat un wordpress si ca ar fi chiar useless. Scopul de a pune asta pe blog este ca-s batran si imi notez ce fac :))

Pentru moment o sa ma multumesc sa testez un singur serviciu, un nginx.

$ kubectl create deployment nginx-app --image=nginx --replicas 2
$ kubectl expose deployment nginx-app --name=nginx-web-svc --type NodePort --port 80 --target-port 80
$ kubectl describe svc nginx-web-svc

Ar trebui ca din decscribe sa vad ce port am:

Nginx pe portul 32433 si ip-ul nodului (oricare din ele ca-s 2 replici, deci 2 ngincsi…)

Voilla, atatea comenzi pentru un nginx gol? Oare cat mai e pana la un wordpress functional?

Testele au vorbit! Dacă folosiți Proxmox pentru a vă construi propriul datacenter (homelab) în sufragerie sau mai bine in debara, probabil v-ați gândit: „Oare TrueNAS ar merge ca VM?” Ei bine, răspunsul este: da, merge. Dar și o Dacie 1300 poate merge pe un drum forestier, doar că s-ar putea să vă trebuiască un ciocan și ceva noroc. TrueNAS, favoritul meu, nu joaca fair cu proxmox. TrueNAS stie sa dea si file level si block prin iscsi… e f nice.

Virtualizarea TrueNAS vine cu beneficii, dar și cu provocări. Dacă acest „bagaj” devine prea greu, există alternative care, deși nu sunt perfecte, s-ar putea să vă facă viața mai ușoară. Hai să vedem despre ce este vorba!


Probleme intalnite

  1. Performanța discului (sau indisponibilitatea lui)
    TrueNAS adoră ZFS. Iar ZFS, ca orice sistem de fișiere sofisticat, vrea acces direct la hardware. Virtualizarea adaugă un strat suplimentar de „telefon fără fir”, iar performanța poate suferi. Tot la fel, in cazul in care faceti passtrhough unui device USB (un seagate pe usb) catre VM-ul TrueNAS se poate sa nu functioneze cum trebuie, asta am patit eu, nu am reusit sa formatez disk-ul sa il folosesc. NU A VRUT. Am testat direct pe fier si a fost ok. Cica problemele ar fi fost cauzate de quirk-urile necesare in TrueNAS dar pentru mine a fost deal-breaker, aveam nevoie de aia 3TB de pe USB.
    Soluție:
    • Configurați PCI passthrough pentru ca TrueNAS să vorbească direct cu discul, nu prin translatorul Proxmox.
    • Nu folosiți fișiere de disc virtuale (.qcow2). TrueNAS vrea „fier”, nu jucării.
  1. Foamea de memorie
    ZFS mănâncă RAM de parcă ar fi la bufet suedez sau la all inclusive la turci. Alocați prea puțin și veți simți cum performanța se îngroapă în swap. Eu am folosit 16GB si cu disk-urile pe care le-am putut folosi totul a fost perfect, saturam reteaua de storage iar latentele din VM-uri erau satisfacatoare. Proxmox poate supraproviziona ram.
    Soluție:
    • Nu fiți zgârciți: dați-i 8-16 GB RAM sau chiar mai mult in functie de cati TB aveti. Dacă serverul dvs. geme, poate e timpul să investiți într-un upgrade.
  1. Rețea lentă
    O rețea prost configurată este ca un drum aglomerat: nimeni nu ajunge la timp. Iar dacă TrueNAS este folosit pentru stocare centralizată, latențele mici sunt cruciale. Pentru un homelab folositi minim 1GB/s si daca este posibil faceti teaming sau creati o retea separata pentru “storage”.
    Soluție:
    • Folosiți adaptoare de rețea virtio. Sunt rapide și compatibile.
    • Puneți TrueNAS pe un VLAN dedicat, să nu se „calce pe cablu” cu restul VM-urilor.
  1. Siguranța datelor
    TrueNAS este construit pentru a proteja datele, dar dacă hardware-ul gazdă clachează, nici cel mai avansat algoritm ZFS nu vă poate salva.
    Soluție:
    • Investiți într-un UPS. Dacă serverul cade la prima pană de curent, sunteți pe cont propriu.
    • Faceți snapshot-uri frecvente în Proxmox sau configurati un backup. E mai bine să aveți un backup decât să plângeți după date.

Alternative: „TrueNAS, hai să luăm o pauză”

Dacă TrueNAS devine mai pretențios decât un critic culinar, există soluții care, deși nu sunt perfecte, pot rezolva multe dintre problemele dvs. de stocare.

1. Unraid

Unraid este genul de prieten care nu cere mult, dar știe să facă treaba. Îți lasă libertatea de a folosi discuri de dimensiuni diferite, iar RAID-ul este mai degrabă opțional. Ca functionalitati este “asemanator” cu TrueNAS, poti porni VM-uri sub el, poti porni containere, poti face snapshot-uri…

De ce să-l alegi?
E simplu de configurat, chiar și pentru începători.
Poate rula și ca NAS, și ca platformă de virtualizare.

Când să-l eviți?
Dacă urăști ideea de a plăti pentru licență.
Dacă îți dorești protecția pe care doar ZFS o oferă


2. OpenMediaVault (OMV)

OMV este un NAS open-source simplu și eficient. E ca un vecin care te ajută cu reparațiile: nu cere mult, dar își face treaba. Functioneaza cu Debian bookworm, este simplu, merge cu 2 vCPU si 4GB ram. 🎯
Il hostez pe Proxmox si este momentan singura solutie care nu inclina balanta in vreo directie gresita.

proxmox

De ce să-l alegi?
Gratuit și ușor de configurat.
Comunitate activă și plugin-uri pentru orice ai nevoie.
N-are foame de resurse.

Când să-l eviți?
Cand ai nevoie si de iscsi
Cand vrei ZFS out of the box
Cand ai impresia ca performantele OMV nu-s … performante.


3. Rockstor

Bazat pe Btrfs, Rockstor este o soluție NAS care știe să facă snapshot-uri și deduplicare fără să se plângă. Nu am testat in detaliu, doar l-am instalat… si m-am plimbat prin interfata. As vrea ca disk-ul extern pe USB sa-l formatez EXT4 si in caz de nevoie sa il deconectez si sa-l montez pe alt hardware.

De ce să-l alegi?
Perfect pentru utilizatorii Linux care vor o alternativă la ZFS.
Simplu de folosit și destul de robust

Când să-l eviți?
Dacă ai nevoie de o comunitate numeroasă și activă.
Cand n-ai incredere (inca) in BTRFS


4. Synology / Asusstor / orice alt NAS disponibil

Dacă nu vrei bătăi de cap, asta este răspunsul. E ca un all-inclusive pentru NAS-uri: plătești și primești totul pregătit. Cu cat ai mai multi bani, cu atat o sa fie tolba mai plina cu feature-uri care de care mai nice 🙂


Concluzie: Nu te stresa, există opțiuni!

TrueNAS este grozav, dar doar dacă îi oferi tot ce cere. Dacă nu vrei să te simți ca un părinte care trebuie să îndeplinească toate mofturile unui copil răsfățat, alternativele precum Unraid, OMV, RockStor sau Synology sunt aici să-ți facă viața mai ușoară, in functie de buget.
Pentru use case-ul meu cel mai ok pare sa fie OpenMediaVault sub Proxmox. Este simplu, nu ai compresie sau deduplicare, nu poate oferi iSCSI… dar nu poti avea in viata toti ce iti doresti. Ii poti atasa hdd-uri usb prin proxmox, poti sa faci si un pic de mirror… Am inchis povestea – am un shared storage si pot sa il folosesc, pentru VM-uri, pentru backups, pentru containere si ce-o mai fi nevoie.

E gata! High Availability, politica de backup globala… shared storage, “vmotion”… totul in 30Wh intr-o stare de aproape idle. Proxmox Cluster în Sfârșit: 3 Noduri, NFS și Consumul de Curent “Eco-Friendly”

După lungi aventuri și cafele încărcate cu speranță, am reușit: am un cluster Proxmox funcțional!

Hardware-ul

“Clusterul” e compus din trei noduri, cu nume de scenă pve00, pve01 și pve02. Iată rolurile fiecăruia:

  • pve00: E ca acel coleg care nu face prea multe, dar e indispensabil. Acesta va fi nodul martor (“witness”) și va oferi storage shared pe NFS pentru câteva VM-uri.
  • pve01 și pve02: Adevărații eroi ai clusterului, gazduind VM-uri și containere LXC. Ei sunt soldații de pe front, duc greul și ne salvează ziua.

Toate acestea rulează pe trei mini PC-uri Lenovo Tiny (m710q și m715q), care sunt ca niște chihuahua hiperactive: mici, dar cu o energie neașteptată. 4CPU si 32GB ram fiecare. Pare putin dar este suficient pentru laboratorare.

cluster

Consumul de energie

Cu tot clusterul „aproape idle”, consumul total de curent este de doar 28-32W. Aproape că te aștepți să vezi un LED aprins și să îți spui: „Esti sigur că merge totul? Nu e doar screensaver-ul?”.

Funcționalitate

Am testat aproape toate funcțiile basic pe care le-am folosit anterior în VMware. Rezultatul? Totul functioneaza ca uns, ca in oil overload. Nu ma asteptam sa fie asa de bine pus la punct… Singurul regret? Ceph. Ar fi fost interesant, dar sunt limitat de un număr insuficient de discuri. (Așa-i când visezi la mamaliga, dar nu ai malai.)

Migrarile de pe un host pe altul: cand VM-ul nu este pe shared storage va fi copiat disk-ul pe storage-ul vecin si memory state. 1-2 pinguri se pierd. Cand este pe shared storage se copiaza doar ram-ul… cand este protejat de HA doar mentioneaza ca migreaza prin HA si nu mai arata altceva.

HA – la fel ca Vmware, se restarteaza vm-ul pe unu din serverele care mai exista si se pune in fencing pe cel care e mort in papushoi.

Hotplug: CPU, RAM, DISK, USB… Network. Cam tot de ce ai nevoie.

Shared storage

Merge cam orice ai: NFS, CIFS, ISCSI, SCSI, FC, GlusterFS, Ceph, ZFS, etc. Am testat cu NFS si CIFS.

Storage pe NFS

Pentru storage-ul shared, am configurat un VM cu NFS pe pve00. Deși nu e cea mai rapidă soluție, și-a făcut treaba impecabil pentru nevoile noastre. VM-urile și containerele sunt mulțumite si am putut porni High Availability.

Am testat OpenMediaVault (OMV) ca soluție de storage, dar mi s-a părut lent comparativ cu așteptările. Ma asteptam sa umplu gigabitul ala dar testele erau undeva intre 78-89 MB/s, TrueNAS cu aceleasi disk-uri este constant, undeva peste 110MB/s. Se poate sa fie nevoie de tuning suplimentar pe OMV.

Tot pe NFS am configurat si Backup-urile VM-urilor mai importante, aici fiind avantajos ca avem o politica globala.

Ce urmează?

Anunț oficial „Next Episode”: TrueNAS – Virtualizare pe Proxmox? Stay tuned!

Până atunci, rămâneți curioși, caffeinați și gata de experimente. Mai avem multe de descoperit în lumea homelab-ului!