Previziuni timide: America o sa devina din ce in ce mai iubita in lume, la exemplul lor China isi ia Taivan, dupa care Trump face un atac supriza la Groenlanda, Rusia se muta si pe alte fronturi…
Bula AI se sparge, OpenAI o sa fie redus la tacere, singurii cu un produs valid raman Google.
Romania nu o sa reuseasca sa reglementeze pensiile speciale, statul roman nu vrea sa declare falimentul dar vor incerca sa faca bani din impozite din ce in ce mai mari. Europa nu o sa reuseasca pana la sfarsitul anului sa se impuna in nici un fel…
Oscarul o sa fie castigat de un film cu pisici care danseaza generat in totalitate cu AI.

Asa cum ne place sa privim inspre viitor, sa ghicim in stele sau in parul pubian prins pe cada de dus, in cafea, in liniile de pe palma, in vibratia zilei s.a.m.d – cum o sa fie 2026? Scenariul este un amestec de SF, Comedie neagra, cele mai proaste sitcom-uri si survivor la antena1. Viitorul arata ca gandurile care ne dau anxietate.

Pe Frontul Geopolitic: Unde se duce lumea?

Previziunile vorbeau despre o Americă brusc “mai iubită” pentru rezerverele de petrol din Venezuela (ironic, având în vedere tensiunile globale), urmată de o mișcare îndrăzneață a Chinei în Taiwan. Sună ca un joc de șah? Nu e sah, e etalare de cohones si pariuri pe faptul ca nimeni nu vrea WW3. Ca tacâmul să fie complet, un “atac surpriză” al lui Trump la Groenlanda (relicva unei intenții reale de cumpărare, acum transformată în scenariu de acțiune) și Rusia extinzându-se pe noi fronturi. Nu zic nimic despre Israel, ei doar nu mai vor hamas pe lume. Definitia hamasului este variabila in functie de narativ.

Sincer asta ne tine cu sufletul la gura, mai ca dabia mai respiram, mai rau decat versiunea alfa-beta covid. Esentialul este clar, resursele raman miza principala si suntem blestemati sa repetam greselile trecutului, pentru ca l-am uitat.

Bula AI se sparge? Adio, OpenAI, Salut, Google?

In mod ironic pentru ca lucrez in IT ma intriga bula AI. OpenAI, Nvidia si Oracle sunt prinsi acum intr-un cerc masturbatoric, ei spun ca nu o fac cand sunt cu plua partenerului in mana. Sper sa intre in faliment pentru ca AI-ul este un produs nociv pentru societate. Brain rot! Eficientizare procese? Imbunatatirea traiului celor care traiesc pe pamant? Nu. Doar imbunatatirea profitului, inrobirea celor care traiesc pe pamant. Masini care se conduc singure, gaini AI.

AI-ul este momentan un miraj, cu fanfara multa, concurenta acerba pentru un singur castigator. Cel care tine actiunile castigatorului in mana. Pentru noi se termina tot intr-o realitate rece, ca un dus pe vremea lui Ceausescu atunci cand faceam economii sa platim datoria externa a Romaniei.

România și Europa: O oglindă tristă a prezentului?

Aici, previziunile au un gust salciu de realism. “România nu o să reușească să reglementeze pensiile speciale,” “statul român nu vrea să declare falimentul, dar vor încerca să facă bani din impozite din ce în ce mai mari.” Sună familiar, nu? Cât timp mai poate dura acest dans politic? Ca sa fie bine nu trebuie sa fie un pic rau? dar noua romanilor nu ne este bine de multa vreme. Suntem satui ca nepotii de sarmale cand petrec vacanta de iarna pe la bunici.

Europa, la rândul ei, este văzută ca un colos lent, incapabil să se impună. Între birocrație și lipsa unei viziuni unitare, continentul pare să navigheze într-o ceață, căutându-și drumul într-o lume din ce în ce mai agitată.

Oscarul pentru Pisicile Dansatoare

Bomboana de pe tort: Oscarul câștigat de un film cu pisici dansatoare, generat integral de AI! O satiră inteligentă la adresa unei industrii care se luptă cu inovația și, în același timp, o premoniție deloc fantezistă.

Concluzie.

Nu trebuie sa ne afundam in pesimism. Lumea este intr-o continua miscare si trebuie sa fim constienti de provocari si sa cautam solutii. Eu sunt inca optimist ca vom vedea pe marile ecrane filmul cu pisici care danseaza, broadway ai! Ay!

Watch your storage like a hawk

• EBS → Stay within 30 GB total for all volumes combined.
• S3 → Keep under 5 GB or set lifecycle rules to auto-delete old files.
• Delete unused volumes and snapshots — stopping an instance isn’t enough.
• Pro tip: Use one volume per instance when possible.

Track your compute hours

• 750 hours/month = one free-tier-eligible instance running 24/7.
• More instances = hours add up across all VMs.
• Run extra VMs for short bursts and stop when not in use.

Avoid “premium” services unless testing briefly

• Some AWS services have no free tier: NAT Gateways, Load Balancers, some RDS setups,
  Provisioned IOPS volumes.
• Spin up, test, and delete the same day to avoid charges.
  

Clean up aggressively

• Delete unused EBS volumes, snapshots, AMIs, idle Elastic IPs.
• Remove old CloudWatch logs.
• AWS charges for provisioned resources, even if idle.

Use the AWS Budgets & Billing Alarms

• Set a $1–$2 monthly budget alert in AWS Billing → Budgets.
• Alerts you early if you exceed free tier limits.
• Prevents surprises like a forgotten NAT Gateway burning $20/month.
  

Extra learner hack: Keep one main free-tier t3.micro/t2.micro running 24/7 for your baseline lab, and spin up larger instances only when actively testing — delete them afterward. Your $100 credit will then go only toward high-power bursts, not slow leaks.

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:

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.

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!

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!

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

HP Smart Array P420, 30W!

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 dificie. 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 pentru selfhosting, 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 pitita, 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. Beneficiile unui plan platit

Daca esti bogat si 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

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.

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:

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

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 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?

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.

2. 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.

3. 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.

4. 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 “am dat cu seen”

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…

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.

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.

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

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 (unrail e pe bani, synology la fel..).
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.

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 clusterului, gazduind VM-uri și containere LXC.

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.

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!

Am inceput cu un Lenovo M715q. Am pus pe el proxmox. Puteam rula VM-uri si LXC-uri iar sistemul atata vreme cat nu trageam de el era destul de silentios. Cu cateva VM-uri pornite (un ubuntu cu apache/php/mysql, un HomeAssistant os, 2 windows 2022) manca in idle cam 7W. 7W si puteai sa dormi langa el.

Cred ca postul asta este mai mult despre ProxMox… Am descoperit ca are backups, folosind politici, out of the box. Great! Puteam scrie backup-urile dupa un schedule, automat, intr-un disk de backup. Super tare, ESXi nu avea asta. ill.ro sta pe proxmox si are si backup-uri, plus homeassistant, care are si el backup-uri. Minunat!

Daca pana acum foloseai VMware ESXi pentru homelab sfatul meu este sa incerci proxmox. Folosesc vmware din 2008 si am fost certificat VCP de la versiunea 4.5 la 6.5, am ceva background pe VMware dar e clar ca Proxmox PVE este excelent, si cred ca este indeajuns de bun sa il pun si pe un mediu de productie. Are cam tot ce avea ESXi si inca niste plusuri, nici nu mai mentionez costul care este mult mai mic!

Pasii urmatori: cluster si shared storage.

Paessler e una din companiile astea.

Paessler are un produs matur pentru monitorizarea infrastructurilor it. Un produs super decent. Costul se facea la senzori monitorizati (1 senzor era de exemplu 1 disk de pe 1 server, care iti arata cat spatiu mai exista, sau procesorul, cat e utilizat). Am inceput cu 1000 de senzori si am ajuns la 5000. Din punct de vedere bugetare, era simplu, costul era decent si fix, era previzibil si nu trebuia sa iei aprobari ca sa cumperi an de an. Licenta era perpetua si cumparai mentenanta si suport.

Mentenanta si suportul pentru licenta perpetua, cum era pana acum au disparut iar pretul subscriptiei creste de vreo 3 ori. Este modelul Brocade de a cerne clientii mici…

Folosesc PRTG de 7 ani si sunt foarte multumit de produs… nu prea au mai inovat ei in ultimii x ani dar produsul e stabil. Poti customiza senzori si daca “le ai” cu scripturile si poti monitoriza cam ce vrei dintr-o infrastructura on prem (sau cloud) fara agenti, prin wmi, snmp, perfmon, ssh, etc… Dupa 7 ani, la renewal-ul anual, ne loveste baiatu de la sales cu costul marit de 3 ori… cu o explicatie cam stupida, dar incluzand disocount de 40% daca comitem pentru 3 ani.

NU

Ramanem la versiunea asta pana cand expira si ne uitam la alternative, ca slava domnului, sunt destule. Nu ne uitam la solarwinds cum nu ne-am uita la Crowdstrike daca vrem antivirus. Poate peste inca 4 ani :))

Ce am incercat pana acum, din lista de FREE’n’Moka sau ShutUpAndTakeMyMoney. Prin incercat zic instalat solutia si testat use case-urile noastre. Pana acum favoritul meu e site24x7.

1. Primul produs testat si luat cotatie – Logic Monitor. Cam de 10 ori mai scump decat noua subscriptie de la PRTG pentru fix aceleasi nevoi de monitorizare. Produsul este cam de 10 ori mai avansat decat PRTG si are integrare in toate cloudurile existente. Stie AWS, GCP si Azure. Iti arata tot intr-un singur dashboard. E customizabil cat se poate si are rapoarte cat cuprinde. Ne-a speriat pretul.
2. CheckMK – m-a dezamagit cumva ca avea agenti si pe langa asta era cam ciudata interfata. Ciudata probabil pentru mine… ca la fel mi-a parut si PRTG prima oara cand am dat ochii cu el, problema cu CheckMK a fost ca intre discovery si adaugat la monitorizare parca trebuia sa mai faci niste pasi inutili. In fine, poate am fost biased. Nu e agentless. Nu am obtinut nici o cotatie de pret.
3. Zabbix – Gratis. Dar munca pe care trebuia sa o depunem sa ajungem la nivelul de monitorizare pe care il avem acum in PRTG ar fi fost titanica. Daca as lua ceva de la zero as alege zabbix… dar nu o luam de la 0 si tot ce era alerta, limita de warning, limita de eroare… trebuia facut de maini dibace. Am 42 de ani si nu mai am chef. Plus ca mai avea nevoie si de agenti…
4. Domotz – Autodiscovery foarte misto, dar nu aveai detaliile out of the box. Trebuia sa pui server cu server ca vrei cel putin disk, ram, cpu. Nu poti crea senzori custom. Pentru monitorizare windows foloseste WinRM si SSH (da, pui ssh pe windows) … si ssh pentru linux-uri
5. WhatsUP Gold – Discovery foarte bun doar ca out of the box iar nu aveai foarte multe lucruri monitorizate. Ping. Pentru mai mult trebuia sa adaugi senzori. Nu mi-a placut pentru ca nu puteam monitoriza “chestiile custom din PRTG”.
6. Grafana si Prometheus – iar, am 42 de ani si am devenit putoare. Arata super dashboard-urile din grafana, dar cand ai multe servere asta inseamna overhead. Instaleaza agenti, pune sursa in prometheus, vezi pe la dashboard-uri… poate pe un set restrans de servere.. acolo unde vrem grafice frumoase.
7. Site24x7 a lu manage engine – nu e agentless dar poti si fara agenti, pui in reteaua in care vrei sa monitorizezi un “On premise poller” setezi credentiale si merge cu WMI si SSH pentru windows-uri si linux-uri. Ce e cu agent iti adauga valoare: aplication performance monitoring, logs monitoring. Rapoarte SLA foarte misto. Integrare cu AWS… si aduce din toate conturile resurse pe care le doresti monitorizate. Cred ca numarul norocos este 7. Se potriveste pe toate use case-urile doar ca inca nu avem un pret…

Mai sunt si alte solutii de monitorizare foarte bune, dar atat am testat si am decis sa ma opresc. Manage Engine mai are OpManager, mai sunt icinga, openNMS, Datadog, NewRelic, Dynatrace, Solarwinds (cred ca trebuie mentionat chiar daca au avut acel faimos data leak)… etc.

Folosesc VMware cam de prin 2008. Prima oara am auzit de el de la un coleg prea entuziast, care spunea atunci ca asta este viitorul. Nu o sa mai avem datacentere pline de servere fizice, sau na, vor mai fi dar cam de 30 de ori mai eficiente dpdv al energiei electrice, al spatiului, al cooling-ului. O sa virtualizam datacentere intregi! Tu iti dai seama? Serveru e un fisier acum, il poti muta cum vrei, ii faci backup usor, exista snapshot si daca strici ceva, pac, revii la snapshot.

Cam de atunci, din 2008 cam asta a fost jobul meu. Administrator de sisteme, cu vmware, cu storage, cu fiberchannel, cu virtualizare de storage, cam tot tacamul. Ce a fost in jurul lui Vmware probabil am testat si administrat. Mi-a placut foarte mult, am inteles cum functioneaza, am construit si la joburi ulterioare, in fine… super.

Vmware a fost cumparat de EMC, am lucrat si cu solutii din portofoliul lor, i-a cumparat Dell, povestea a continuat, am descoperit prin 2017 Compellent, PowerProtect… iar acum dupa 17 ani de munca in zona asta imi dau seama ce dinozauristica este tehnologia pe care o cunosc si am promovat-o atata vreme cu entuziasm.

Vmware a fost vandut catre Broadcom. Bye VMware – Welcome Proxmox.

Aici incep sa se schimbe un pic lucrurile. Versiunea gratuita dispare, se trece la alt model de subscriptie care face Vmware sa fie mai scump, echipele de suport si toate procedurile se muta la Broadcom. Peste VMware apare “by Broadcom”. Clientii vechi deja cauta alternative sau deja se muta pe alte tehnologii, alti vendori deja au track-uri de migrare de la VMware.

Foloseam VMware vsphere acasa pentru laboratoare / sandbox-uri. Imi parea asa de simplu incat nu am cautat nimic care probabil era mai ok pentru use-case-urile mele. Acum nu ca n-as fi putut sa iau “de pe torente” un esxi si sa-l folosesc in continuare, am preferat sa caut…

Am vorbit cu niste colegi (mai demult) de Proxmox, ca pare misto, ca e free… pentru o companie care nu foloseste toate tool-urile vmware sau incepe sa isi faca o infrastructura, pare alegerea ideala… Nu l-am testat.

Welcome Proxmox VE.
VM-uri, Containere… poate! As vrea sa il pun si intr-o infrastructura mai “enterprise” cu un shared storage, sau chiar sa folosesc Ceph (in loc de vmware vsan)… si sa vad si cum e… in real life, in productie :D.
Pana acum mi-a placut ca poti sa faci backup unui VM fara software aditional (este in interfata), poti sa muti masina de colo colo printre noduri, imi place UI-ul, imi place!

Bye VMware – Welcome Proxmox! Acum dinozaurul s-a pus pe invatat si alte lucruri, ca nu-l mai angajeaza nimeni daca stie bine de tot vmware. Era la moda devops, acum vad ca se cauta SRE, care e urmatorul trend? Toti vor in cloud?