SMB Cluster közös storage-el (NFS/iSCSI) Docker swarm-al

Linux-haladó

Sziasztok!

 

Az alabbi user case megvalosithato kevesbe robosztus rendszerrel? (tehat nem Kubernetes)

https://www.tuxera.com/blog/verifying-tuxera-smb-servers-automatic-conn…

 

En Docker Swarm-ra gondoltam NFS-t tudo NAS-al mint shared storage.

A Docker Swarm eseten is szukseges az Nginx reverse proxy (vagy HAproxy)? A virtualis IP-t maskepp nem lehet esetleg "hazon belul" megoldani?

 

Ha latott mar valaki valami jo HowTo-t ilyen confighoz, megoszthatna.

 

Koszi!

 

(nem prod ready-nek kell, csak tesztnek)

  • 521 megtekintés

( Vamp | 2022. 04. 11., h – 11:24 )

Szerkesztve: 2022. 04. 11., h – 11:30

Alakul a dolog!

 

Swarm-al csinaltam egy manager-worker 2 tagu clustert.

 

Containernek teszt jelleggel ezt hasznaltam, de persze csinalhat az ember maganak a sajat szaja ize szerint Image-t.

 

https://hub.docker.com/r/elswork/samba

 

Csinaltam egy volume-t a kozos NFS storage-hez, ezt csatolja fel a container mindig. 
 

docker volume create --driver local \
  --opt type=nfs \
  --opt o=addr=192.168.92.13,rw,noatime,rsize=8192,wsize=8192,tcp,timeo=14,nfsvers=4 \
  --opt device=:\volume1\teszt 	\

A samba container egy egy replikas docker service.  Mindket Node-ra raktam keepalived containert, amivel szepen megy a virtual IP.

docker run -d --name keepalived --restart=always \
  --cap-add=NET_ADMIN --cap-add=NET_BROADCAST --cap-add=NET_RAW --net=host \
  -e KEEPALIVED_UNICAST_PEERS="#PYTHON2BASH:['192.168.92.10', '192.168.92.11']" \
  -e KEEPALIVED_VIRTUAL_IPS=192.168.92.12 \
  -e KEEPALIVED_PRIORITY=200 \
  osixia/keepalived:2.0.20

 

A bajaim meg:

 

- Egyreszt meg van hozzaferes gond a share-el, de ez annyira nem lenyeges, sztm valami az NFS oldalon lesz

- A masik gondom. Ugye van egy manager es egy worker a clusterben. Alapbol a workeren fut a container, ha az leesik, szepen atmaszik a managerre (ezen ugye engedelyezve van a worker mod is). Ez eddig patent, a gond, hogy ha visszajon a worker, nem maszik vissza ra a szolgaltatas... Utana olvastam, Swarm-ban ez koncepcio, hogy ne induljon el foloslegesen ujra a container mashol, ha mar ugyis egy mukodo rendszeren fut.

Jo lenne ezt rendszeren belul lekezelni, de ha maskepp nem megy, akkor irok a managerre egy bash scriptet, ami azt figyeli, hogy ha rajta fut egy adott container, de kozben a worker elerheto, akkor force-olja az update-et (ez atmozgatja egybol a containert)

 

Jobb lenne elegansabban, de nincs mas otletem... nektek esetleg?

pont hogy az kell, hogy a workeren fusson.

 

A cel az lenne, hogy adott egy manager(ami worker is) illetve egy only worker. Alapbol mindent a (only)workeren iindit a swarm,  ha a node(ot futtato server) kihal alola, akkor a manager elinditja sajat magan a containert. Ez eddig ok is. a problema az, hogy ha ujra elindul a only worker node, a container nem indul ujra a visszatert node-on. Ez azert gond, mert ha a manager ezek utan valamikor a jovoben osszefossa magat, akkor a container nem fog elindulni a workeren, mert nincs ami megmondja neki, hogy ezt tegye meg (ugye erre csak a manager node-ok kepesek)

Miért? 1 mangered van? Utolsó emlékeim szerint abból sem árt 3 db. De az egész swarm lényege az lenne, hogy neked ezzel NEM kell foglalkozni, majd ő intézi.

+ javaslom megnézni ucarp hálózati beállítást az IP címre. Szerintem rögtön megúsznád a proxyt és a keppalive-ot.

Esetleg a placement preference megoldhatja, ezzel ugye azt tudod megmondani, hogy milyen node-okat preferáljon (de ha nincs olyan, akkor is lesz deploy). Azt sajnos nem tudom (nem próbáltam, mindig legalább 1 manager + 2 worker-t használok), hogy ez indukál-e redeploy-t automatikusan, ha visszajön egy preferált node (és eddig nem volt olyan).