Permalänk

Proxmox lagring

Insåg för ett tag sedan att jag börjat lite i fel ände och satte mig ner för att läsa på om proxmox eftersom jag bestämt mig för att använda det som hypervisor istället för exsi.

Jag har läst massor om olika alternativ på kluster och olika lagringstyper, men hittar väldigt lite om varför man bör välja det ena eller det andra (i ett format som jag begriper alltså), så söker lite input.

Mina önskemål/behov/förutsättningar ser ut såhär:

Jag har två fysiska servrar med helt olika hårdvara, en "light" strömsnål miniserver och en DL380 G7.
Miniservern ska köra brandvägg och AP controller hade jag tänkt, och den stora får köra allt annat.
Bägge servrarna har lokal disk som VM:ar kan ligga på och jag har ett NAS som jag sedan kan backuppa mot.
I den stora servern har jag möjlighet att använda den inbyggda raidkontrollern, men jag har även möjlighet att byta ut den mot ett hba-kort.
Den lilla har enbart en sata-disk idag, men där finns plats för en till.

* Jag vill kunna migrera VM:ar mellan servrarna men jag känner inget behov av live-migrering.
(jag är medveten om att migrera router/brandvägg inte är så praktiskt ;), men övriga VM:ar hade varit bra att tillfälligt kunna flytta runt lite).

* Jag vill kunna göra backupper på hela VM:ar under drift, med konfigurerbart antal versioner sparade till NAS:et.

* Thin provisioning (finns det nått bra ord på svenska??) känns som en bra ide, men där finns säkert nackdelar som jag inte tänkt på.

Ja det är väl egentligen det hela. Går det att från en bild få en överblick hur alla VM:ar på båda servrarna mår samtidigt är det en fördel, men med hela två servrar kan jag nog hantera det oavsett.

I proxmox manualen går de igenom alla olika varianter av filsystem, men vilket borde jag använda mig av egentligen?
(en manual som nog slår alla rekord i antal olika förkortningar dessutom ).

Permalänk
Medlem

Länge sedan jag satte upp en helt ny installation, och ännu längre sedan jag gjorde det med deras installationsskiva. Så min info kan vara lite gammal, men min rekommendation skulle vara
Lilla servern stoppar du i en likadan disk till i, partionerar upp typ 32GB till proxmox som du kör med MD-raid, resten av utrymmet kör du en tom partition på där du sen kör ZFS-mirror.

Stora servern antar jag att du har lite mer disk i, där kör du HBA-kortet, eller konfar HP-kortet till att presentera diskarna rakt igenom. 2 SSDer till OS som du gör likadant med som i den lilla, men du skapar också en typ 8GB partition på varje som du kör ZFS-ZIL på, resten av utrymmet på SSDerna har du till ZFS-cache, resten av diskarna som helst ska vara lika stora kör du som raw-devicer och kör en ZFS-mirror på.

Kör du inte ZFS-på NASen så kör med qcow2 som filformat för gästernas diskar så får du snapshots då kan skicka över.

Permalänk
Medlem

Du ska kunna koppla ihop servrarna och köra migrering mellan dem.

Med thin provisioning finns risken att man inte har full koll på det faktiska diskanvändningen och att man plötsligt fyller den fysiska disken till max så att allt stannar. Ingen fara hemma men värre för ett företag. Sedan är det sämre prestanda än med thick provision men tror inte du märker något. Jag kör thin i min server

Permalänk
Skrivet av Xcorp:

Länge sedan jag satte upp en helt ny installation, och ännu längre sedan jag gjorde det med deras installationsskiva. Så min info kan vara lite gammal, men min rekommendation skulle vara
Lilla servern stoppar du i en likadan disk till i, partionerar upp typ 32GB till proxmox som du kör med MD-raid, resten av utrymmet kör du en tom partition på där du sen kör ZFS-mirror.

Ska se vad som går att göra i den lilla, den är rätt begränsad, däremot ZFS ovanpå en mjukvaruraid låter fel i mina öron. Borde väl vara bättre att köra ZFS mirror direkt och sen skapa separata volymer ovanpå det?
Begränsningen på den lilla maskinen är att minnet är begränsat och ZFS gillar minne . Får räkna på det och se om det går ihop sig.
De tjänster jag tänkt köra i den skriver minimalt till disk så det går nog att hålla ZFS ganska kort, men minimikraven har jag förstått från FreeNAS forumet att man inte ska rucka på . Det är inte omöjligt att det bara sitter 8gb minne i den just nu så isåfall blir det till att handla lite mer innan den går "i produktion".

Skrivet av Xcorp:

Stora servern antar jag att du har lite mer disk i, där kör du HBA-kortet, eller konfar HP-kortet till att presentera diskarna rakt igenom. 2 SSDer till OS som du gör likadant med som i den lilla, men du skapar också en typ 8GB partition på varje som du kör ZFS-ZIL på, resten av utrymmet på SSDerna har du till ZFS-cache, resten av diskarna som helst ska vara lika stora kör du som raw-devicer och kör en ZFS-mirror på.

Jo den har rätt gott om disk, tror det sitter 300gb diskar i den nu så två till OS och sex till lagring bör ge ca 800 gib, bör räcka rätt långt.

Skrivet av Xcorp:

Kör du inte ZFS-på NASen så kör med qcow2 som filformat för gästernas diskar så får du snapshots då kan skicka över.

Nas:en kör FreeNAS så det är inte riktigt samma ZFS, så kanske att gcow2 är att föredra.

Skrivet av jocke92:

Du ska kunna koppla ihop servrarna och köra migrering mellan dem.

Med thin provisioning finns risken att man inte har full koll på det faktiska diskanvändningen och att man plötsligt fyller den fysiska disken till max så att allt stannar. Ingen fara hemma men värre för ett företag. Sedan är det sämre prestanda än med thick provision men tror inte du märker något. Jag kör thin i min server

Eftersom jag mest hållit på med fysiska servrar med (oftast) rymliga diskar så känns det lite märkligt att fundera på hur mycket/lite man ska tilldela en VM. Jag har redan misslyckats ett par gånger och varit alldeles för snål och det är rätt klöddig att utöka i efterhand. Ok att när man gjort det några gånger så lär man sig så det blir enklare, men det känns ändå betydligt smidigare att ge varje VM lite extra utrymme, omutifall

Sen att man bara behöver backa upp det verkligt använda känns ännu bättre .

Det lär nog bli en hel del labbande innan jag känner att jag har kontroll på det här .
Speciellt hur de båda servrarna kan fungera ihop, manualen pratar mycket om kluster, men det funkar ju inte med två helt olika maskiner antar jag. Men efter några nätters labbande klarnar det säkert.

Hoppas jag

Permalänk
Medlem

Skall man ha lokal disk skulle jag helt klart välja ZFS, spegel eller raid-z/z2. Du får nyttan av effektiva ZFS snapshots, och i nyare Proxmox versioner går det även att konfigurara upp schemalagd replikering mellan hostarna.

Permalänk
Medlem
Skrivet av hjälpsam:

Ska se vad som går att göra i den lilla, den är rätt begränsad, däremot ZFS ovanpå en mjukvaruraid låter fel i mina öron. Borde väl vara bättre att köra ZFS mirror direkt och sen skapa separata volymer ovanpå det?

Självklart menar jag att du kör MD för den lilla OS-delen och ZFS-mirror för datalagringen, inte ZFS ovanpå MD.

Skrivet av hjälpsam:

Begränsningen på den lilla maskinen är att minnet är begränsat och ZFS gillar minne . Får räkna på det och se om det går ihop sig.
De tjänster jag tänkt köra i den skriver minimalt till disk så det går nog att hålla ZFS ganska kort, men minimikraven har jag förstått från FreeNAS forumet att man inte ska rucka på . Det är inte omöjligt att det bara sitter 8gb minne i den just nu så isåfall blir det till att handla lite mer innan den går "i produktion".

En vanlig missuppfattning, ZFS kräver verkligen inte så mycket minne som många skriver, kör du däremot med dedup så äter det minne för att hålla uppe prestandan. Har du för lite minne så kommer det gå långsammare, men inte sluta funka. Detta för att då måste den göra lookups mot disk hela tiden istället för att hålla tabellerna för dedup och liknande i RAM.

Skrivet av hjälpsam:

Jo den har rätt gott om disk, tror det sitter 300gb diskar i den nu så två till OS och sex till lagring bör ge ca 800 gib, bör räcka rätt långt.

Nas:en kör FreeNAS så det är inte riktigt samma ZFS, så kanske att gcow2 är att föredra.

Det ska vara lugnt att skicka ZFS-snapshots däremellan.

Permalänk
Medlem
Skrivet av hjälpsam:

Eftersom jag mest hållit på med fysiska servrar med (oftast) rymliga diskar så känns det lite märkligt att fundera på hur mycket/lite man ska tilldela en VM. Jag har redan misslyckats ett par gånger och varit alldeles för snål och det är rätt klöddig att utöka i efterhand. Ok att när man gjort det några gånger så lär man sig så det blir enklare, men det känns ändå betydligt smidigare att ge varje VM lite extra utrymme, omutifall

Sen att man bara behöver backa upp det verkligt använda känns ännu bättre .

Det lär nog bli en hel del labbande innan jag känner att jag har kontroll på det här .
Speciellt hur de båda servrarna kan fungera ihop, manualen pratar mycket om kluster, men det funkar ju inte med två helt olika maskiner antar jag. Men efter några nätters labbande klarnar det säkert

När det är virtuellt kan du utöka disken i efterhand om det blir trångt i den virtuella maskinen.

Ett kluster kan du nog inte köra men det du vill är att maskinerna är betrodda för varandra. Men namnet kan vara samma i proxmox för båda funktionerna

Skickades från m.sweclockers.com

Permalänk
Skrivet av Xcorp:

Självklart menar jag att du kör MD för den lilla OS-delen och ZFS-mirror för datalagringen, inte ZFS ovanpå MD.

Precis, men den har bara plats för två diskar och ZFS vill hantera hela diskar.

Skrivet av Xcorp:

En vanlig missuppfattning, ZFS kräver verkligen inte så mycket minne som många skriver, kör du däremot med dedup så äter det minne för att hålla uppe prestandan. Har du för lite minne så kommer det gå långsammare, men inte sluta funka. Detta för att då måste den göra lookups mot disk hela tiden istället för att hålla tabellerna för dedup och liknande i RAM.

Jag vet att ZFS i sig inte egentligen har så stora minnesbehov, men jag räknar såhär:

enligt manualen är minimum för Proxmox är 1GB, rekommenderat är 8GB. Antar att det innebär att Proxmox med ZFS klarar sig på 3-4 gb
pfSense klarar sig på 2gb men det är på gränsen, så 3 gb borde den få.

Jag har (tror jag) 8 gb just nu i maskinen.

så väldigt liten marginal om min matte stämmer, funkar det att köra snålare så blir marginalerna så klart rimligare.

Skrivet av Xcorp:

Det ska vara lugnt att skicka ZFS-snapshots däremellan.

Najs, det ger ju fler möjligheter.

Skrivet av jocke92:

Ett kluster kan du nog inte köra men det du vill är att maskinerna är betrodda för varandra. Men namnet kan vara samma i proxmox för båda funktionerna

Låter som att det är det jag ska leta efter det för det är ju det jag vill ha.

om detta stämmer är HA något man konfigurerar på VM nivå, är det så enkelt är det ju helt lugnt? För då är det bara att köra kluster.
- > https://pve.proxmox.com/wiki/High_Availability_Cluster
(hoppas på skitväder i helgen så jag kan sitta inne och labba med proxmox , men säg inget till sambon... ).

Permalänk
Medlem
Skrivet av hjälpsam:

Precis, men den har bara plats för två diskar och ZFS vill hantera hela diskar.

Funkar lika bra att ge ZFS en partition på varje disk. Om jag inte minns helt fel så kan du köra proxmox med ZFS som root också, men kommer inte ihåg.

Citat:

Jag vet att ZFS i sig inte egentligen har så stora minnesbehov, men jag räknar såhär:

enligt manualen är minimum för Proxmox är 1GB, rekommenderat är 8GB. Antar att det innebär att Proxmox med ZFS klarar sig på 3-4 gb
pfSense klarar sig på 2gb men det är på gränsen, så 3 gb borde den få.

Jag har (tror jag) 8 gb just nu i maskinen.

så väldigt liten marginal om min matte stämmer, funkar det att köra snålare så blir marginalerna så klart rimligare.

Vad gör som gör att pfsense kräver 2-3GB? Du borde utan problem kunna köra den på 0.5-1GB, och återigen ZFS åter så mycket minne det kan, men finns det inte minne så går det bara långsammare, det slutar inte funka.

Permalänk
Skrivet av Xcorp:

Funkar lika bra att ge ZFS en partition på varje disk. Om jag inte minns helt fel så kan du köra proxmox med ZFS som root också, men kommer inte ihåg.

Enligt manualen ska det inte vara något problem att boota så länge man inte har uefi.

Skrivet av Xcorp:

Vad gör som gör att pfsense kräver 2-3GB? Du borde utan problem kunna köra den på 0.5-1GB, och återigen ZFS åter så mycket minne det kan, men finns det inte minne så går det bara långsammare, det slutar inte funka.

Ärligt vet jag inte varför, men det är vad min pfsense drar idag. Men det kan ju också helt enkelt bero att det finns minne, ibland är det ju så enkelt. Sen är det inte helt omöjligt att det finns inställningar som är mindre lämpliga, Snort kan ju dra rätt bra med minne bland annat. Jag har faktiskt inte koll, det är så länge sedan jag gjorde den installationen och sen har det bara snurrat på.

Jag vill verkligen komma igång med det här projektet nu
Igår kväll fick jag det mesta på plats i racket och kunde börja prova att starta upp maskiner. I kväll får jag börja med att riva ut en del igen för det främre stället har kommit för nära dörren så stänger jag dörren knäcker jag fiberkablarna i switchen meh, slarvigt men tydligen har jag mätt fel på en halv centimeter eller nått när jag skruvade ihop racket .

Permalänk

Efter omstart av pfsense drar den under en gb nu så då känns det lugnare igen

Permalänk

Det var ju riktigt fint väder så blev inte så mycket tid framför datorn, men lite har jag hunnit med i alla fall.

Proxmox installerat på bägge maskinerna och ett kluster skapat där båda är med.
Så långt är det klart.

Det jag lärt mig såhär långt är att man skulle ha bestämt sig för vilka IP-adresser maskinerna skulle haft från början för det är klöddigt att ändra i efterhand. Proxmox vill inte använda dhcp utan kör helt statisk ip. Det funkade sådär med mitt nätverk hemma Men även det lätt fixat med en statisk tilldelning i routern så namnuppslag funkar.

Statiskt IP i kombination med att jag av någon anledning fått fel nätmask på den ena orsakade en hel del förvirring innan jag insåg vad det berodde på. (jag kunde inte komma åt gui:it trots att det funkade utmärkt att pinga maskinen, men med fel nätmask ville den ju inte prata med min dator).

Efter att bägge är ihoplagda i ett kluster ser jag bägge servrarna oavsett vilken servers gui jag ansluter till, däremot är det något strul med rättigheter för det poppar upp en inloggningsruta när jag väljer "den andra" servern som inte går att komma förbi, så där står jag just nu.

ZFS funkar bra att boota ifrån, kör så på båda servrarna nu, OVS är inlagt men har inte börjat skapa nätverksstrukturen ännu.

Det går inte fort när det går långsamt

Permalänk
Medlem

@hjälpsam: Tipset från mig är att skippa OVS,

Angående problem med rättigheter och IP-adresser, gör om och gör rätt från början, det är betydligt lättare än att försöka fixa i efterhand då det är en hel del tjänster som ska ändras och uppdateras..

Permalänk
Skrivet av Xcorp:

@hjälpsam: Tipset från mig är att skippa OVS,

Det gör jag gärna, men har du nån motivering varför?

Permalänk
Medlem
Skrivet av hjälpsam:

Det gör jag gärna, men har du nån motivering varför?

Jag har provat lite och inte haft någon bra erfarenhet av det. Ska du bara köra ett eller ett par olika VLAN så är bryggor så mycket lättare.

Permalänk

Nu är båda uppe och snurrar som de ska.
Jag tror att mitt problem till största del berodde på att de inte var överrens om klockan .
Den stora hade biosklockan ställd på UTC (och antagligen bara "ganska rätt") medan den lilla hade lokal svensk tid i bios. Det borde inte spela någon roll så fort systemet bootat, men av någon anledning spökade det till det. Efter att ha pekat ut samma tidsserver i bägge och startat om började allt lira som det skulle.

Jag får läsa på mer om OVS vs native för nu är nästa steg att peta ihop det virtuella nätverket.

och om nån fattar varför i hela världen man inte kan se en VM:s ipadress i gui:t får gärna berätta det för det borde vara den enklaste saken i världen, och en av de mera intressanta sakerna man vill veta när man skapar en ny VM.

Permalänk
Medlem
Skrivet av hjälpsam:

...
och om nån fattar varför i hela världen man inte kan se en VM:s ipadress i gui:t får gärna berätta det för det borde vara den enklaste saken i världen, och en av de mera intressanta sakerna man vill veta när man skapar en ny VM.

Kör du KVM så är ju gästen i stora drag helt isolerad från värden, så det finns inget enkelt sätt att plocka ut gästens IP.
Hade du kört Containers istället så syns den. Sen kan man ju tycka att om gästen har motsvarande vmware-tools/guest-additions (vet inte vad det heter för QEMU) så hade ju proxmox kunnat läsa ut det den vägen. Lägg en feature-request så löser dom nog det

Permalänk
Skrivet av Xcorp:

Kör du KVM så är ju gästen i stora drag helt isolerad från värden, så det finns inget enkelt sätt att plocka ut gästens IP.
Hade du kört Containers istället så syns den. Sen kan man ju tycka att om gästen har motsvarande vmware-tools/guest-additions (vet inte vad det heter för QEMU) så hade ju proxmox kunnat läsa ut det den vägen. Lägg en feature-request så löser dom nog det

Visst är den isolerad, men det hade varit enkelt att plocka upp det på vägen, trafiken går ju trots allt internt så att ha något i bakgrunden som lyssnar på DHCP-trafiken borde varit simpelt.

Men man kan installera qemu-guest-agent, ett annat alternativ är att ställa in ett ip i brandväggen för VM:en redan när man skapar den.
Får pilla vidare för att hitta vilket som passar mig bäst.

Permalänk
Medlem
Skrivet av hjälpsam:

och om nån fattar varför i hela världen man inte kan se en VM:s ipadress i gui:t får gärna berätta det för det borde vara den enklaste saken i världen, och en av de mera intressanta sakerna man vill veta när man skapar en ny VM.

Kolla på qemu-guest-agent , finns i alla distributioner jag testat, då dyker IP adress/er upp.

Permalänk
Medlem
Skrivet av hjälpsam:

och om nån fattar varför i hela världen man inte kan se en VM:s ipadress i gui:t får gärna berätta det för det borde vara den enklaste saken i världen, och en av de mera intressanta sakerna man vill veta när man skapar en ny VM.

Nu förstår jag inte riktigt, om du kollar under "Network" för valfri VM/CT så listas ju IP-adressen.
Om du använder CLI och t.ex CT (container):

root@pve:~# pct list VMID Status Lock Name 100 running unifi01 101 running pihole01 root@pve:~# pct config 100 arch: amd64 cores: 1 hostname: unifi01 memory: 1024 net0: name=eth0,bridge=vmbr0,gw=192.168.1.1,hwaddr=62:98:FA:61:28:B0,ip=192.168.1.6/24,type=veth onboot: 1 ostype: debian parent: backup rootfs: local-lvm:vm-100-disk-1,size=5G swap: 0 root@pve:~#

Edit : Jaha, nu förstår jag vad som menas.
Jag använder inget annat än containers så att man måste krångla extra när det gäller VMs var faktiskt nytt för mig.

# qm agent 102 info No Qemu Guest Agent #

Visa signatur

Marantz NR1605, Rotel RB1090, Ino Audio piPs
SMSL SP200 THX Achromatic Audio Amplifier 888, SMSL M400, Audio-Gd NFB-11 (2015), Objective2+ODAC RevB, Audeze LCD-2 Rosewood, Monoprice M1060, ATH-M40x, Sennheiser HD660S, DROP X KOSS ESP/95X, Koss KPH30i, DROP X HiFiMan HE4XX

Permalänk
Medlem
Visa signatur

Primär maskin: iPad Pro 12,9tum 2022 med Magic Keyboard.
Sekundär maskin: Ryzen 9 5900x, Radeon 7900 XTX, 32GB RAM, monitor: OLED42C24LA
2st NUC 9 Pro Kit - NUC9VXQNX Ubuntu server för diverse.
PSN ID:iller Xbox live:illerG Wii U:illerG Switch:iller

Permalänk

Precis, för VM:s måste man installera Qemo-guest. Plus att man måste aktivera "Qemu Agent" i options för den VM:en för det är inte aktivt som standard.

Nåväl, för de flesta moderna os ska väl inte det vara något problem, jag irriterar mig mest på att det inte ens nämns i manualen nånstans.

Idag har jag lärt mig byta nätverkskort i proxmox (flyttade ett kort fysiskt i maskinen för jag hade satt det i fel kortplats), var ju inte så klurigt faktiskt.

Det jag pysslat med i dag är att försöka få udp portar forwardade i docker med en docker-compose.yml.

Det har jag inte lyckats med ännu.
(men så är jag fortfarande nybörjare på docker också ).

omada:~/docker-omada$ sudo iptables -t nat -L -n Chain PREROUTING (policy ACCEPT) target prot opt source destination DOCKER all -- 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination DOCKER all -- 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 172.17.0.0/16 0.0.0.0/0 MASQUERADE all -- 172.18.0.0/16 0.0.0.0/0 MASQUERADE tcp -- 172.18.0.2 172.18.0.2 tcp dpt:8088 MASQUERADE tcp -- 172.18.0.2 172.18.0.2 tcp dpt:8043 Chain DOCKER (2 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 RETURN all -- 0.0.0.0/0 0.0.0.0/0 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8088 to:172.18.0.2:8088 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8043 to:172.18.0.2:8043

Permalänk

fortsatta äventyr :).

Efter en och en halv kvälls mixtrande och googlande gav jag upp med den dockern och installerade mjukvaran själv istället.

wget och apt install och fem minuter senare var allt uppe och snurrade och klart konfigurerat.
Tror jag skjuter lite på att studera docker, vi verkar inte vara helt kompatibla :).

Med proxmox är det lättare att komma överrens,
Vi funkar rätt bra ihop numera.
Att köra kluster med bara två maskiner fungerar, men det blir lite begränsningar.
Så fort en är offline blir den kvarvarande maskinen ganska låst, det går inte att starta en VM eller starta om en VM eller göra några ändringar av inställningar.
(det går att komma runt tillfälligt så klart men är rätt opraktiskt).

Det innebär också till exempel att efter ett strömavbrott kommer min router inte att starta upp förrän bägge servrarna är uppe, och jag hade inte planerat att ha den stora att autostarta utan jag hade tänkt att ta det manuellt.

Det kan vara ide att fixa en tredje instans så att det alltid finns tillräckligt med "röster" i klustret. Får fundera på det framöver. Jag såg att det skulle vara möjligt att köra på en raspberry, men det verkar vara ett rejält fulhack och det vill jag helst slippa. Däremot någon liten atom skulle kunna hantera det. Men samtidigt känns det lite onödigt med en burk bara för det. Och jag tror att den stora servern räcker till det jag vill göra så det finns inget behov av mer resurser av den anledningen heller.

En fundering uppstod när jag läste det här i manualen "Proxmox VE assigns a single vote to each node by default." - Innebär det att jag skulle kunna konfigurera så att min lilla server har två röster? Och att den isåfall funkar på egen hand sen för att den har två av tre röster i klustret?

Ska faktiskt testa det ikväll.

Permalänk

Som det verkar funkar det alldeles utmärkt att ge en host två röster och den andra en röst .
Efter omstart startar den lilla servern upp sin VM trots att den är ensam i klustret. Najs.

Morgondagens äventyr blir att byta plats på servrarna fysiskt. Vet inte hur ni andra placerar era servrar, men min tanke är att stoppa den varmaste längst ner så att den får kallast inluft och inte behöver jobba så hårt för att hålla tempen, sedan i nån sorts ordning uppåt i racket.

Som det är nu är det 14 grader i källaren och stora servern rapporterar 31 grader för inlet temp medan naset som ligger längre ner knappt klarar att hålla arbetstemperaturen uppe på diskarna. Byter jag plats på de två borde det bli bra mycket bättre för båda maskinerna.

Som det är nu viner det rätt bra om HP:ns fläktar när de ligger och pendlar mellan 50-70%.

Permalänk
Medlem

Brukar lösa problemet med röster genom kommandot "pvecm expected 1" men verkar återställas efter omstart. Har du listat ut nått sätt att lösa det på förutom att ge en host mer röster?

Permalänk
Skrivet av JamSod:

Brukar lösa problemet med röster genom kommandot "pvecm expected 1" men verkar återställas efter omstart. Har du listat ut nått sätt att lösa det på förutom att ge en host mer röster?

I mitt fall är det enkelt eftersom det är den lilla servern som jag vill ska kunna fungera på egen hand, medan den stora servern inte har det behovet. Då kan jag ge den lilla två röster medan den stora behåller en röst.

När enbart den lilla är igång har den då 66% av rösterna i klustret.

Det är bara att uppdatera corosync.conf i etc/pve/ med nano, öka config version med ett, och ändra antalet röster på den hosten som ska klara sig själv till 2.

Det slår igenom direkt och man behöver inte starta om.

Det finns säkert nån nackdel med att göra såhär, men ingen jag vet om (ännu).

Permalänk

Ytterligare två veckor har gått, jädrar vad tiden går fort!?!

Proxmox och jag är fortfarande vänner. Däremot förra helgen höll vi på att bli lite osams, men det verkar faktiskt inte som att det var Proxmox som bråkade utan min switch. Jag försökte mig nämligen på att slå ihop två av SFP+ interfacen till ett bond men det funkade inte bra, massa paketförluster på den ena och andra kostigheter. Till slut gav jag upp och återställde till att bara använda en sladd. Tidigare idag skapade jag ett bond med två vanliga portar i switchen och det funkade direkt så det kan vara att switchen inte kan köra LACP på 10gbe-portarna (eller att nätverkskortet inte klarar det).

LOL, när jag skaffade den lilla servern trodde jag aldrig att jag skulla använda alla nätverksportarna (den har sex stycken), men nu använder jag fem av dom :). En till admin/inlogg proxmox, sen WAN, två till LAN(LACP) och en till separat proxmox nät. Admin-uttaget används även av Omada-VM som körs på den lilla servern.

Nåväl, mina erfarenheter så långt av Proxmox, det funkar riktigt smidigt att installera och köra direkt på en zfs-mirror, funkar även bra att skapa en zfs på enbart en disk under installationen och lägga till en andra i efterhand.

Kör man på standardalternativet skapas det en pool (rpool) med två dataset (ROOT & data) och det är såklart i data som virtuella maskiner lagras. I minin sitter det två 120gb ssd i mirror och det är mer än jag nånsin kommer att behöva, men så räknar jag inte med att behöva oroa mig för att skriva sönder diskarna heller.

root@mini:~# zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 7.60G 99.9G 104K /rpool rpool/ROOT 2.45G 99.9G 96K /rpool/ROOT rpool/ROOT/pve-1 2.45G 99.9G 2.45G / rpool/data 5.13G 99.9G 96K /rpool/data rpool/data/vm-100-disk-0 4.11G 99.9G 4.11G - rpool/data/vm-101-disk-0 1.03G 99.9G 1.03G - root@mini:~#

Något som funkar sämre är att skapa fler lagringspooler via GUI:t, på den stora servern ville jag skapa en pool av sex diskar som tre vdevs i mirror men det fixade jag inte utan fick ta det på kommandoraden istället. ZFS är som tur inte så komplicerat (ehm) så nu har jag en extra större lagringspool fixad och klar.

Jag har mountat en samba share från mitt nas som proxmox kör automatiska backupper av VM:ar mot, funkar utan några problem. En VM med ubuntu server 18.10 blir lite drygt 2GiB så man kan ju spara rätt många om man skulle vilja.
Jag har inte tagit tag i att ordna backup av själva proxmox ännu utan jag har lagt mest tid på installation och konfigurering av den nya pfSense-VM:en. Gårdagen ägnades till stor del åt att stånga pannan blodig under försöken att få till ett fungerande VLAN med dhcp och allt annat, men till slut så insåg jag att problemet låg i inställningarna i switchen och sen gick det rätt mycket fortare att få rätt på det.
Det är rätt svårt att felsöka VLAN insåg jag, det är ju gjort för att det inte ska synas liksom . Med lite mer rutin hade det så klart gått fortare men det tog ett tag innan jag kom överrens med netplan så jag riktade mest frustration mot den stackaren .

Dock är jag inte helt såld på netplan som ny nätverkskonfigurering i ubuntu, men det verkar funka skapligt i alla fall. Jag har bara så svårt att förstå att man väljer ett format som yaml som är så horribelt gnälligt på att varenda mellanslag måste vara korrekt, det känns som att man skapar fler felmöjligheter nu än tidigare. Är man van vid yaml sen tidigare är det rätt ok att jobba med men ändå, känns korkat oavsett .

Min tidigare oro över att minnet på 8gb inte skulle räcka verkar ha varit helt obefogad. Trots pfBlocker med rätt stora blocklistor drar inte pfSense över en gb minne just nu. Jag ska läga på snort också tänkte jag men sen är den klar att sättas i drift. Jag har fortfarande bevakning på minne på tradera men det känns inte så prioriterat ;).

Däremot ska jag köra lite tester för att se hur den beter sig under tyngre last, inte för att jag egentligen är speciellt orolig utan mest för att jag nu har alla möjligheter att labba med den innan den kopplas in "på riktigt".

Slutsatsen är väl att jag helhjärtat kan rekommendera att köra zfs-mirror på hela diskar direkt från standardinstallationen.
Med en liten ! dock, standard så görs installationen utan swap. Det är bra att vara medveten om det och vilka konsekvenser det kan ha (och även varför det görs så).

det var väl allt för idag, nu blir det öl och film, med hopp om lite snogging senare (alternativt snzzzz, vem vet)

Permalänk
Medlem

@hjälpsam: Kul att du delar med dig av dina erfarenheter.

Visa signatur

Marantz NR1605, Rotel RB1090, Ino Audio piPs
SMSL SP200 THX Achromatic Audio Amplifier 888, SMSL M400, Audio-Gd NFB-11 (2015), Objective2+ODAC RevB, Audeze LCD-2 Rosewood, Monoprice M1060, ATH-M40x, Sennheiser HD660S, DROP X KOSS ESP/95X, Koss KPH30i, DROP X HiFiMan HE4XX

Permalänk

Jag försöker skriva lite sånt som jag själv vill läsa

och så försöker jag balansera ut alla mina (dumma) frågor med vad jag lärt mig, om det hjälper, eller roar någon är det en extra bonus.

Har inte hunnit labba nåt mer sen sist, vet inte om det är nån influensa eller nått annat men det har mest kännts som sirap i hjärnan när jag suttit vid burken om kvällarna så det har inte hänt mycket alls.

Pysslat lite mer med pfSense för att försöka lära mig om hur jag bäst konfigurerar den i den nya miljön.
Min plan är att ha två WAN, min ISP ger mig två ipadresser och idag så har jag en switch efter fiberboxen där en port går till min router och sedan lan och en andra port går till en separat server.
Med de nya grejjerna är det tänkt att bägge linorna går in till samma pfSense och att trafiken på det ena WAN:et går vidare internt på ett VLAN som sen till att börja med enbart används av en virtuell server på den stora proxmox hosten, dvs egentligen bara en klon av den fysiska servern jag redan har idag.

Skillnaden blir att allt hamnar bakom samma brandvägg och att jag bara kör virtuella servrar sen.

Jag har lärt mig hur man får två WAN in till pfSense med två olika ipadresser, de var inte så klurigt till slut. Men svårt att hitta hjälp på nätet för det mesta handlar om hur man använder två olika wan för lastbalansering eller redundans och det är ju lite annorlunda.

Ett tips är att om man sätter upp en ny pfSense instans så ska de två första interfacen alltid vara wan och lan, och eventuella extra interface gör man sen. Det står överallt i manualen att man kan konfigurera alla interface som man vill, och det är helt sant, men allt förutsätter att det första är WAN och det andra är LAN vilket bland annat innebär att det skapas lite default brandväggsregler som är rätt bra om de hamnar rätt, dessutom i flera dialoger kommer det första interfacet att visas som WAN och det andra som LAN oavsett om man döpt dem annorlunda, det underlättar inte heller om det i en meny står LAN(WAN) där det ena är defaultnamnet och det andra det namn jag själv givit (och vilket som är vilket får ni gissa själva ).

Nä, först WAN, sen LAN och sen resten så blir allt mycket enklare.
Går båda WAN:en mot samma dns-server behöver man på det andra WAN-interfacet ange ett nytt hostname på interfacefliken, annars kommer pfSense att skicka med samma hostname i bägge dhcprequesten och då kommer man (oftast) inte att få två ipadresser, finns säkert undantag men som jag förstått det är det så det normalt funkar. Med två olika hostname däremot funkar det bra.

Jag valde att från proxmox ge pfSense tre "näverkskort" dvs jag kopplade min WAN-bridge två gånger till pfSense-VM och LAN-bridge en gång. Då ser pfSense det som tre nätverksportar och man behöver inte mixtra någon annanstans. Funkar väldigt smidigt.

Kvar att fundera över är hur uppdelningen av det interna lanet ska se ut, om jag ska behålla det som idag med allt i en hög eller separera med ett eller ett par VLAN.