by ·0 Comments

Uptime Kuma este un tool dragut de monitorizare, face automat rapoarte SLA, monitorizeaza site-uri, este destul de util. Pentru a monitoriza ill.ro folosesc altceva (UptimeRobot), m-am gandit sa fie independent de homelab, ca daca pica homelab-ul nu mai imi zice nimeni ca a cazut site-ul…
Voi folosi ArgoCD pentru a testa si invata cum functioneaza acest tool… l-am instalat si pana acum e doar o interfata web… Asadar sa instalam cu ArgoCD.

Pentru pasii astia avem niste prerechizite:
1. Un share nfs pentru persistent storage (il foloseste uptime kuma ca sa tina minte tot ce face)
2. Un cont de github sau orice repo, eu o sa folosesc github ca inca nu am deployat asa ceva in homelab.
3. metalLB functional 🙂

1. Mai intai share-ul NFS: am folosit v3 pentru simplitate, am permis accesul full din reteaua de acasa, desigur in afara homelab-ului vom avea autentificare si altele. Am creat un share numit uptime-kuma.

Pe nodurile k8s (control/worker) vom instala nfs-common si testam daca share-ul nfs este disponibil si putem scrie pe el.

apt install -y nfs-common
mkdir /mnt/test-nfs
mount -t nfs -o nfsvers=3 IP_NFS:/uptime-kuma /mnt/test-nfs
touch testnfs
cd /mnt/test-nfs && ls

Ar trebui sa vedem fisierul. Daca e acolo, inseamna ca nodurile noastre pot accesa NFS, trecem mai departe.

2. Github. Facem un nou repo, o sa il numesc argoCD si vom crea intr-un director nou urmatoarele fisiere:

Prima oara facem un namespace, fisierul uptimekuma-namespace.yaml.

apiVersion: v1
kind: Namespace
metadata:
  name: uptime-kuma

Definim un persistent volume – uptimekuma-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-uptime-kuma
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=3
  nfs:
    path: /uptime-kuma
    server: IP_NFS #adresa ip a serverului nfs

Persistent volume claim uptimekuma-pvclaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: uptime-kuma-pvc
  namespace: uptime-kuma
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  storageClassName: slow

Definim serviciul – uptimekuma-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: uptime-kuma-tcp
  namespace: uptime-kuma
spec:
  type: LoadBalancer #nu specificam ip, lasam metallb sa aleaga pentru noi
  ports:
  - name: web-ui
    protocol: TCP
    port: 3001
    targetPort: 3001
  selector:
    app: uptime-kuma

Si in final, deployment-ul uptimekuma-deplyment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: uptime-kuma
  namespace: uptime-kuma
spec:
  selector:
    matchLabels:
      app: uptime-kuma
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: uptime-kuma
    spec:
      containers:
      - name: uptime-kuma
        image: louislam/uptime-kuma:1
        imagePullPolicy: IfNotPresent
        env:
        # only need to set PUID and PGUI because of NFS server
        - name: PUID
          value: "1000"
        - name: PGID
          value: "1000"
        ports:
        - containerPort: 3001
          name: web-ui
        resources:
          limits:
            cpu: 200m
            memory: 512Mi
          requests:
            cpu: 50m
            memory: 128Mi
        livenessProbe:
          tcpSocket:
            port: web-ui
          initialDelaySeconds: 60
          periodSeconds: 10
        readinessProbe:
          httpGet:
            scheme: HTTP
            path: /
            port: web-ui
          initialDelaySeconds: 30
          periodSeconds: 10
        volumeMounts:
        - name: data
          mountPath: /app/data
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: uptime-kuma-pvc

Pasul 2, sa intram in ArgoCD, sa definim un repository si o aplicatie. Rezultatele ar arata ca in printscreen-urile de mai jos. Avem nevoie de 2-3 lucruri:
– repository URL: tip https sau cum vreti voi, si path-ul.
– project – o sa fie default, ca nu am altceva definit
– cluster – o sa aleaga automat clusterul pe care este instalat
– path: uptimekuma – e directorul unde am pus tot.
– sync: am lasat manual

Dupa ce accesezi aplicatia si dai click pe sync, argo o sa downloadeze yaml-urile din repo, din directorul ales si o sa inceapa sa le aplice.
Rezultatul ar trebui sa arate asa:

Teoretic ar trebui sa poti accesa uptime kuma, pe ip-ul pe care il aloca metallb… si sa vezi interfata.

Orice schimbare a yaml-urilor din github vor fi semnalate de ArgoCD. Daca ai pus sincronizarea pe automat ar trebui ca orice modificare faci sa fie deployata in Kubernetes automat, sa zicem ca modifici numarul de replici (pod-uri) pentru aplicatia ta.. sau faci un update… Mai jos exemplu:

by ·0 Comments

“BestMan” m-a sfatuit sa ma uit si la ArgoCD. Rachete, magie, gitops, kubernetzi…
Sa incepem cu o traducere:

Argo CD este un instrument declarativ CICD pentru aplicațiile Kubernetes. Acesta utilizează stilul GitOps pentru a crea și gestiona clustere Kubernetes. Atunci când se fac modificări în configurația aplicației din Git, Argo CD o compară cu configurația aplicației care rulează și notifică utilizatorii pentru a sincroniza starea dorită cu cea actuală.
Argo CD a fost dezvoltat în cadrul proiectului Argo al Cloud Native Computing Foundation (CNCF), un proiect destinat în special gestionării ciclului de viață al aplicațiilor Kubernetes. Acest proiect include, de asemenea, Argo Workflow, Argo Rollouts și Argo Events. Fiecare dintre acestea rezolvă un set specific de probleme în procesul de dezvoltare agilă și contribuie la livrarea scalabilă și securizată a aplicațiilor Kubernetes.

Cumva in github pui yaml-urile, asta verifica ce e acolo si face treaba. Asta e magie, ca pana acum stateam cu 20j de fisiere yaml pe nodu de control si le pierdeam, le suprascriam, nu mai stiam care fisier e ce imi trebuie… nah, gandire de sysadmin.
Am deja cont de github, o sa fac un repo nou si o sa il folosesc pentru a instala “Uptime Kuma” cu ArgoCD.

Instalarea ArgoCD e simpla, am facut un namespace nou si am folosit manifestul lor.
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Dupa 2-3 minute am vazut si podurile:

Mai devreme am pus MetalLB si as vrea sa il folosesc sa ajung la ArgoCD. Se poate folosi si nodeport dar e mai elegant asa, fara sa accesezi porturi ciudate. Dezavantajul pe care il vad eu pe termen lung o sa trebuiasca sa extinzi pool-ul de ip-uri folosit de metallb. Deci, revenim:
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

Teoretic acum ar trebui sa am ArgoCD publicat pe unu din ip-urile alea din loadbalancer, pe porturile 443 si 80.

O sa avem nevoie de parola (userul e admin). Avem o parola random creata la instalare…
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
Accesam 192.168.111.220:80, user si parola avem. Iaca!

Avem ArgoCD functional, teoretic putem incepe sa il folosim.
Next post, instalare “Uptime Kuma” cu ArgoCD.

by ·0 Comments

MetalLB este o soluție de LoadBalancer pentru clusterele Kubernetes care de pe infrastructură bare-metal, asa cum am si eu in HomeLab. Spre deosebire de cloud-uri (eks de ex) unde ai deja solutii native… pe onprem (bare metal) ai nevoie de o solutie pentru a expune serviciile catre retea si de acolo… mai departe, pe internet daca este cazul 😀

Instalarea MetalLB

Eu am folosit manifestul lor..
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/main/config/manifests/metallb-native.yaml
In cateva zeci de secunde se for initializa toate componentele si vom avea ceva de genul
kubectl get pods -n metallb-system

Pentru a configura MetalLB vom avea nevoie de un spatiu de ip-uri din zona in care tinem si nodurile de k8s. Daca avem DHCP va trebui sa rezervam zona aceea… Creaza un fisier de ex metallb-config.yaml si aplica configuratia.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: default-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.111.220-192.168.111.230
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertisement
  namespace: metallb-system

kubectl apply -f metallb-config.yaml

Destul de simplu… pentru a vedea logurile metallb

kubectl logs -n metallb-system -l app=metallb

Ca sa ii vedem utilitatea putem sa cream un nginx mic si stingher, facem un yaml nou, nginx-lb.yaml iar la serviciu specificam tipul LoadBalancer.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-lb
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-lb
  template:
    metadata:
      labels:
        app: nginx-lb
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-lb
  namespace: default
spec:
  selector:
    app: nginx-lb
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

Se aplica configuratia, dupa care K8s va crea un POD conform specificatiilor si un serviciu prin care publicam nginx-ul pe portul 80.
kubectl apply -f nginx-lb.yaml

Va trebui sa se regaseasca in lista serviciul si un IP din pool-ul setat mai sus pentru metallb.

Din browser va trebui sa puteti accesa serviciul pe portul 80, pe acel ip.

Easy peasy!

by ·0 Comments

In postul trecut am scris despre un NAS home-made. Nu e o idee rea, ar fi fost maximum de performant pentru ce am eu nevoie dar nu am facut proiectul. M-am oprit la un NAS comercial, adica ala din titlu. Am vazut niste dezavantaje care m-au enervat, in speta lipsa pe piata a placilor de baza cu 4-6 porturi SATA si 2 NVME-uri. Domne, nu exista! Eu spun ca e blat cu aia care fac NAS-uri, ca altfel cum sa nu fie posibil sa pui 2NVME si 4SATA pe langa un PCIEx cu care sa extinzi cu diverse nebunii?

Am ales calea usoara, nu imi pare rau, ba mai mult decat atat, chiar ma bucur ca am facut pasul.

Configuratia este
– 2 nvme x 512GB – folosit pentru cache, raid0 ca sa am mai mult. Riscul este ca daca moare vreunu as putea sa pierd date…. (filme, vm-uri sau containere de test, deci nimic grav)
– 4 sata x 10TB HGST HUH721010ALE604, raid 5. M-am gandit sa le pun la raid10 dar pierdeam 2 disk-uri de capacitate. Asa un disk poate sa pice si nu pierd date vs 2 disk-uri care pot pica. E safe si asa, parerea mea.
– 32 GB RAM – 2 sodimm-uri de 16GB de la Kingston, pe care le aveam deja.

Likes:
– Compact si cat de cat silentios
– 2 x 2.5gbps retea
– Plex / Qbittorrent / *arr ruleaza direct pe NAS, nu mai trebuie sa ruleze pe nodurile de proxmox
– Out of the box cam orice share ai nevoie, pot sa il folosesc ca timemachine pentru laptops

Software-ul pe care il poti instala pe el este cat se poate de divers, folosesc deja container station si am cateva containere Docker, printre care si tehnitium dns pe care il folosesc pentru dhcp dar si DNS blackhole in locul lui PiHole. Container station poate porni si k3s. Pe langa container station mai este un Virtualisation Station in care poti rula VM-uri micute (nu as recomanda ceva resource intensive din cauza procesorului)…

Consum:
– In jur de 40W in idle. Daca as fi avut sistemul de operare instalat pe NVME-uri ar fi intrat in idle disk-urile rotative si as fi economisit vreo 20W… asta atata vreme cat nu ar fi soft nici un request catre ele (qbittorrent oprit, nfs oprit…) deci nu se aplica.

Il folosesc deja sa rulez din proxmox VM-uri de pe un shared storage (NFS mi-a parut cel mai simplu si rapid), am caching pe acel volum deci nu trag “direct” de pe discurile rotative – cache read-write, evident. Il folsesc sa fac backup-uri VM-urilor din proxmox, zilnic.
In laboratorul de k8s (kubernetes) deja e folosit pentru persistent storage… Very nice!

by ·0 Comments

Un Network Attached Storage (NAS) este o solutia pentru stocarea datelor pe un sistem care are si ceva redundanta, iti tine datele protejate printr-un RAID, mai ai si alte 2-3 feature-uri cum ar fi backup, etc. În loc să investesc într-un NAS comercial (Synology, QNAP, etc), am decis să construiesc unul home-made cu componente custom, dar la un preț mult mai accesibil. Un NAS comercial poate fi mai simplu dar cine nu are chef de un challenge? :))
Asta e faza de documentare.

Componentele Hardware

Pentru acest setup, am ales următoarele componente – lista se poate schimba:

  • Carcasa: Jonsbo N2 Mini-ITX Black (cam 20cm/20cm/23cm – e cubica)
  • Placa de bază: Gigabyte H610I DDR4, Intel H610, Socket 1700, mITX
  • Sursa: Sharkoon SilentStorm SFX Bronze 450W – 80Plus Bronze
  • Procesor: Intel Core i3-12100 3.3GHz LGA1700 12M Cache Boxed CPU
  • Memorie RAM: G.Skill Aegis DDR4 32GB (2x16GB) 3200MHz CL16 1.35V XMP 2.0
  • SSD SATA pentru OS: Kingston SSD
  • Hard Disk-uri pentru stocare: 4 x HGST HUH721010ALE604 (10TB fiecare)
  • NVMe pentru caching: Reutilizare NVMe 512GB de pe pve01 și pve02
  • Mai am un adaptor HP Smart Array P420 controller cu 1GB, cu 2 porturi SAS cu split in 8 porturi SATA pentru ca cele 4 porturi onboard ar asigura conectivitate pentru doar 4 disk-uri…. si eu am mai multe.

Sistemul de Operare: TrueNAS Core

Ca sistem de operare am ales TrueNAS Core, pe care l-am mai testat in trecut si mi-a placut ca este customizabil si pare ca acopere cam toate usecase-urile de care am nevoie, un sistem de operare open-source bazat pe FreeBSD, recunoscut pentru fiabilitate și suportul nativ pentru ZFS.
TrueNAS imi va permite sa am si cateva VM-uri always on, sau containere…

Configurarea Disk-urilor cu ZFS

Discurile vor fi setate intr-un raid, un pool ZFS configurat astfel:

  • 3 HDD-uri pentru date
  • 1 HDD pentru paritate

De asemenea, voi utiliza un NVMe pentru caching, ceea ce va îmbunătăți semnificativ performanța accesului la date. ZFS oferă:

  • Caching – folosește RAM și SSD pentru accelerarea accesului la date.
  • Redundanță și fiabilitate – configurarea RAID-Z1 permite ca un disc să pice fără pierderi de date.
  • Snapshots și rollback – in special util daca ai VM-uri…
  • Compresie automată – economisește spațiu fără impact major asupra performanței.

Cu un impact mare pe RAM pot porni si deduplicare – cam 1GB la 1TB de date. Cu 32GB ram nu prea as putea sa fac asta fara sa consum tot ram-ul, cred ca ram la compresie, mai salveaza acolo un pic de storage.

Utilizările NAS-ului

NAS-ul nu va fi doar un simplu spațiu de stocare, ci va funcționa și ca un home-server:

  1. Server de Plex – pentru streaming media (filme, muzică)
  2. Apache-PHP-MySQL – pentru hostarea site-ului asta sa zicem
  3. Stocare de date pentru media – pentru nr.1
  4. Target iSCSI pentru VM-uri – VM-urile de pe pve00, pve01 și pve02 vor putea folosi NAS-ul ca storage shared, permițând High Availability (HA)
  5. Technitium DNS – pentru gestionarea DHCP și DNS în rețea
  6. Servarr Suite – implementare Radarr și Sonarr
  7. Backup Repository – cel mai probabil, un share NFS pentru HomeLab
  8. Nod witness pentru clusterul PVE – va ajuta la menținerea quorum-ului în cazul clusterului Proxmox

Extindere viitoare: Cluster Kubernetes și upgrade de rețea

Dacă rezultatele sunt pozitive, voi lua în considerare refolosirea clusterului Proxmox (pve00, pve01, pve02) pentru a crea un cluster Kubernetes bare-metal… si ma gandeam ca as putea adauga o placa de retea de 2.5gbps, ca sa nu am un bottleneck in retea. (+switch ca acum am doar 1gbps)

Dezavantaje:

Deși un NAS home-made oferă flexibilitate și performanță la un preț mai mic, există câteva dezavantaje față de un sistem NAS comercial:

  • Consum mai mare de energie – sistemul asta poate sa consume mai mult curent decat un NAS comercial
  • Factorul de formă și zgomotul – poate nu la fel de compact si de silentios

Estimari consum (W)

Voi face o estimare aproximativă a consumului de energie în regim idle pentru ca 80% din timp sa fie idle, parerea mea:

  • Procesor Intel Core i3-12100 – ~10W în idle
  • Placă de bază + RAM 32GB DDR4 – ~8-10W
  • SSD SATA Kingston (pentru OS) – ~2W
  • NVMe SSD pentru caching – ~3W
  • HDD-uri 4x HGST HUH721010ALE604 – ~5W per HDD în idle → ~20W total
  • Sursa Sharkoon SilentStorm SFX Bronze 450W – Eficiență ~85%, deci pierderi de ~5W în idle
  • HP Smart Array P420 controller cu 1GB,– ~30W

Estimare totală în idle: ~80-85W

Cel mai mare consumator este HP Smart Array. În funcție de activitatea discului și a procesorului, consumul poate crește, mai ales în load (unde poate ajunge la peste 100W, lejer as spune 150W in load mai serios). Dacă HDD-urile intră în sleep mode, consumul poate scădea cu 20W in total (si asta e doar teoretic pentru ca o sa avem ZFS si o sa doarma din parti).

Un NAS QNAP TS-464 are un consum în idle de aproximativ 18-25W fără HDD-uri și în jur de 45-55W cu 4 HDD-uri HGST HUH721010ALE604. În load, consumul poate ajunge la 65-80W (are o sursa de 90W) în funcție de utilizare. Prin comparație, NAS-ul home-made de mai sus consumă ~80-85W în idle și poate ajunge la 110-115W+ în load.

Cost și concluzie

Costul total al componentelor a fost de aproximativ 2500 RON, o sumă sub prețul unui NAS comercial cu discuri și performanțe similare. Prin această abordare DIY, am obținut un sistem scalabil (mai pot adauga / schimba ram-ul, pana la 64GB cat imi permite placa de baza), performant (cu i3-ul ala generatia 12 poti face multe) și adaptat exact nevoilor mele. Consumul lunar ar putea fi de aproximativ 65-70KWh, transformat in minim 50 de lei in plus pe factura de curent, pentru sistemul home made, si un pic mai mic pentru un sistem comercial (pentru qnap, 25 de lei in plus pe luna la factura de curent).
Cel mai mare consumator sunt disk-urile si adaptorul SAS. 4 disk-uri sata, 1 disk ssd sata, 1 nvme. loc de expansiune pentru 1 disk dar as avea incredere aproape totala in sistem.

Mai am statia mea de lucru, cu 64GB ram, i7-12700K, 4 nvme-uri (1x1TB+3x2TB) si are deja 6 porturi sata. Daca ii adaug 4 disk-uri sata ajunge la un consum idle asemanator cu ce vreau eu sa construiesc 🙂 oare se merita sa fac un sistem nou? (approx 45W idle + 20W de la 4 sata…)

Pentru a reduce consumul:

  • Adaptorul HP Smart Array P420 poate fi inlocuit cu altceva – ceva gen “pciexpress to 4*sata adapter” sau as putea folosi m2-ul de wifi sa conectez 2 sata. ar scadea cu 30w consumul in idle…
  • As putea lua o placa itx cu procesor mai slab integrat (sunt unele cu Celeron J sau N100) – dar tradeoff e performanta mai mica si ne limitam doar la NAS, nu si VMs si nebunii)
  • As putea schimba procesorul cu Intel Pentium Gold G7400…
  • As putea sa-l tin oprit.

Concluzie

E prea mult

adaptor m2-sata (merge pe m2-ul de wifi)
adaptor m2 la 6 sata (merge pe m2-ul de nvme)
adaptor pciexpress la 4 sata, pe singurul pciexpress (sunt si versiuni cu mai multe sata)

HP Smart Array P420, 30W!