HPE met Linux (Ubuntu) failover/redundancy

[Waxyen]

Mijn vraag

Ik wil twee linux servers opzetten, die kopies van elkaar zijn (master/slave). Het zijn NAS servers (zelf opgezet, Ubuntu) met een aantal Docker containers voor een paar extra functionaliteiten. Hoe kan ik deze zo linken, dat de data gesynchroniseerd blijft tussen de slave en de master? Het is de bedoeling dat de content van de master automatisch op de slave komt.

Mijn idee is om de server qua netwerk zo op te zetten

master:
x.x.x.10 > deze interface wordt gebruikt, de rest van het systeem is gelinkt via dit IP-adres
x.x.x.11 > deze interface wordt niet gebruikt

slave:
x.x.x.11 > deze interface wordt gebruikt, maar alleen zodat deze remote benaderd kan worden.
x.x.x.10 > deze interface wordt niet gebruikt.

Wanneer de master kapot gaat, hoeven alleen wat internetkabels omgeklikt te worden, waarna het systeem weer bruikbaar moet zijn.

Ik wil dus graag weten welke software betrouwbaar (het meest betrouwbaar) is, zodat de slave altijd up-to-date blijft.


Relevante software en hardware die ik gebruik
HPE Proliant servers
Ubuntu Linux


Wat ik al gevonden of geprobeerd heb
Ik wil graag weten of iemand hier ervaring mee heeft. Het mag gerust wat kosten, ik wil voornamelijk een wat meer robuuste oplossing.

[DeBolle]

Wat zijn eigenlijk de eisen wat betreft beschikbaarheid? Een simpele rsync setup gaat al heel lekker, een clustersetup met failover is dan weer HA.
Verder zou ik een (off site) backup er ook bij doen - cloud sync mogelijkheden zijn er in overvloed.

[Hero of Time]

Gebruik een virtueel IP dat op de 'master' is toegekend en alle clients naartoe verbinden. Dan hoef je geen fysieke kabels om te gooien, alleen het IP verhuist. Dat kan je automatiseren via heart-beat.

Het in sync houden van de data kan je doen met drbd. Kijk daar eens naar.

[HKLM_]

Ik zou een hypervisor installeren op de machine en de linux wens als vm gaan draaien.

Neem bijvoorbeeld de hyper-v core en laat de vm iedere 30 seconden, 5minuten of 15 minuten repliceren met een andere hyper-v. De replica service van hyper-v tcp/ip failover doet zodat je vm bij een failover dezelfde gegevens behouden.

Dit zit tegenwoordig allemaal standaard in hyper-v en is 5 minuten config werk.

[ Voor 12% gewijzigd door HKLM_ op 09-11-2019 08:48 ]

[Hero of Time]

HKLM_ schreef op zaterdag 9 november 2019 @ 08:47:
Ik zou een hypervisor installeren op de machine en de linux wens als vm gaan draaien.

Neem bijvoorbeeld de hyper-v core en laat de vm iedere 30 seconden, 5minuten of 15 minuten repliceren met een andere hyper-v. De replica service van hyper-v tcp/ip failover doet zodat je vm bij een failover dezelfde gegevens behouden.

Dit zit tegenwoordig allemaal standaard in hyper-v en is 5 minuten config werk.

TS heeft een NAS systeem gebouwd en maakt hiermee efficiënt gebruik van z'n schijfruimte. Waarom zou hij dit allemaal opnieuw moeten gaan opbouwen op een Hyper-V omgeving dat ook nog eens zelf schijfruimte nodig heeft?

Virtualisatie is niet hét antwoord op alle vragen mbt HA maken van een dienst.

[HKLM_]

Hero of Time schreef op zaterdag 9 november 2019 @ 11:00:
[...]

TS heeft een NAS systeem gebouwd en maakt hiermee efficiënt gebruik van z'n schijfruimte. Waarom zou hij dit allemaal opnieuw moeten gaan opbouwen op een Hyper-V omgeving dat ook nog eens zelf schijfruimte nodig heeft?

Virtualisatie is niet hét antwoord op alle vragen mbt HA maken van een dienst.

Dude het is een tip en een core variant van hyper-v kan je op een 5GB hdd draaien. Dan zal er voor TS nog zat "efficiënt gebruik van z'n schijfruimte" beschikbaar zijn. Heb je uberhaupt ooit serieus met de core variant gewerkt? Tevens heeft het virtualiseren gewoon voordelen m.b.t het direct op de hardware installeren maar ik dacht dat je dat wel zou moeten weten

Ik geef de TS een oplossing welke hij als hij wilt in nog geen twee uurtjes uit de grond kan stampen en het is aan de TS wat hij daar mee gaat doen. Linux zal ook zat voordelen hebben maar maakt het nodeloos ingewikkeld als TS nu al niet weet wat hij er mee aan moet om het HA te krijgen.

[ Voor 15% gewijzigd door HKLM_ op 09-11-2019 11:17 ]

[Hero of Time]

HKLM_ schreef op zaterdag 9 november 2019 @ 11:14:
[...]

Dude het is een tip en een core variant van hyper-v kan je op een 5GB hdd draaien. Dan zal er voor TS nog zat "efficiënt gebruik van z'n schijfruimte" beschikbaar zijn. Heb je uberhaupt ooit serieus met de core variant gewerkt? Tevens heeft het virtualiseren gewoon voordelen m.b.t het direct op de hardware installeren maar ik dacht dat je dat wel zou moeten weten

Die 'voordelen' waar jij het over hebt zijn er niet in de opzet van de TS. Die heeft alles al redundant staan. Het enige dat nog gedaan moet worden, is het in sync houden van de data. Daar heb je echt geen hypervisor voor nodig, met extra lagen en alles wat er bij komt. Een NAS draai je bij voorkeur niet virtueel vanwege de extra disk latency die het oplevert. Dat wil je niet.

[HKLM_]

Hero of Time schreef op zaterdag 9 november 2019 @ 11:17:
[...]

Die 'voordelen' waar jij het over hebt zijn er niet in de opzet van de TS. Die heeft alles al redundant staan. Het enige dat nog gedaan moet worden, is het in sync houden van de data. Daar heb je echt geen hypervisor voor nodig, met extra lagen en alles wat er bij komt. Een NAS draai je bij voorkeur niet virtueel vanwege de extra disk latency die het oplevert. Dat wil je niet.

TS heeft nog helemaal niks redundant staan ja hij heeft twee servers maar dat is niet redundant. Hij heeft het zelfs over

Wanneer de master kapot gaat, hoeven alleen wat internetkabels omgeklikt te worden, waarna het systeem weer bruikbaar moet zijn.

Dat is helemaal niet nodig als je je NAS gewoon als VM hebt draaien en direct beschikbaar hebt op een tweede host met TCP/IP failover. Tevens is het hebben van een VM een super oplossing voor je back-up op het uitbreiden van storage of resources.

Een NAS draai je bij voorkeur niet virtueel vanwege de extra disk latency die het oplevert. Dat wil je niet.

Daar zijn ook zat oplossingen voor zoals bijvoorbeeld SSD cashe

Voor TS komt er nog meer kijken dan even wat data syncen want hoe fix je via een data sync ff snel dat de server er binnen 1 minuut weer is als de master down gaat? Met mijn Tip is dit zelf volledig te automatiseren en hoeft TS niet met kabels in de weer en kan die gewoon op zijn stoel blijven zitten.

[ Voor 22% gewijzigd door HKLM_ op 09-11-2019 11:26 ]

[Hero of Time]

HKLM_ schreef op zaterdag 9 november 2019 @ 11:22:
Voor TS komt er nog meer kijken dan even wat data syncen want hoe fix je via een data sync ff snel dat de server er binnen 1 minuut weer is als de master down gaat? Met mijn Tip is dit zelf volledig te automatiseren en hoeft TS niet met kabels in de weer en kan die gewoon op zijn stoel blijven zitten.

Heb jij zelf überhaupt met heart-beat en drbd gewerkt? Want met HB ben je binnen enkele seconden over na het down gaan van je master. Hoef je ook de machine niet opnieuw op te starten.

Downtime is ook een ding, zeker voor een NAS. Een minuut is veel te lang.

[CAPSLOCK2000]

Laten we de "je doet het verkeerd"-discussie een keer overslaan, zeker omdat we niks weten over de wensen en behoeftes van de TS.

Welk NAS-protocol wordt er gebruikt, NFS of iets anders?
Wat is belangrijker, beschikbaarheid of integriteit van je data?
Wil je dat de fail-over handmatig wordt gedaan of liever automatisch? (Met twee systemen is handmatig vaak verstandig om het handmatig te doen).
Hoe veel tijd mag dat maximaal kosten?
Hoe veel tijd mag de data van slave achter lopen op de master? Is een dag oud ook goed of mag het niet meer dan een paar seconde zijn?

Het risico dat ik zie met twee systemen met dezelfde IP-adressen is dat het onduidelijk kan zie wie de master is en wie de slave, en voor je het weet kopieer je de schade ook mee.

De twee meest gebruikt oplossing zijn denk ik rsync en drbd. Met rsync maak je op gezette tijden (bv eens per uur) een (slimme) kopie van A naar B. Simpel en overzichtelijk.
Met DRBD maak je een virtuele harde schijf die op beide systemen tegelijk beschikbaar is.
Vaak wordt dat gecombineerd met een virtueel IP-adres dat automatisch overschakelt naar het systeem dat de master is, maar dat hoeft niet, en kan zelfs onwenselijk zijn.

[Waxyen]

Ten eerste: geweldig dat er zoveel reacties en ideeen zijn!

Hoe goed en stabiel werkt rsync? Ik gebruik het vaak, maar ik weet niet wat het doet als je het om de zoveel tijd laat draaien.

De master server zal voornamelijk gebruikt worden als NAS, dus er zal heel veel GB's gesynct moeten worden met de slave.

Ik zoek vooral een simpele oplossing. Het is helemaal geen probleem om handmatig docker containers te moeten starten op de slave en internetkabels om te klikken. Als ik dit stabiel heb draaien kan ik kijken naar heartbeats en failover.

@CAPSLOCK2000
1. SMB, NFS, FTP, AFP (vanalles wel)
2. beschikbaarheid is belangrijker
3. handmatig lijkt mij minder foutgevoelig, maar ook minder werk. Dit is acceptabel en voorlopig het doel.
4. Het mag gerust wat tijd kosten, maar het moet vrij snel kunnen denk ik
5. Hoe recenter de data, hoe beter. Maar een dag achter lopen is helemaal geen probleem.

De schade mee kopieren is mogelijk, maar redelijk goed af te vangen. Docker containers zijn prima in de hand te houden, niet leesbare data zou een hele server niet stuk moeten maken. Het gaat er vooral om dat wanneer hardware faalt, de andere server gebruikt kan worden.

De rest van de reacties bevat ook nog een paar vragen, maar volgens mij heb ik die zo beantwoord. Laat me weten als dat niet zo is.

Kort over hypervisor: ik denk niet dat ik dit wil. Het voegt (waarschijnlijk onnodig) overhead toe voor een oplossing die ik wil bouwen.

[Waxyen]

Ik wil graag een korte update geven voor mensen, die net als ik, op zoek zijn naar een toffe oplossing.

Ik heb momenteel twee servers aan elkaar gekoppeld met Syncthing. Synchting is open-source (imho een grote plus) en het werkt via een peer-to-peer protocol. https://syncthing.net/

Mijn overweging en keuze voor Syncthing komt doordat de servers nu ook heel eenvoudig via het internet gesynchroniseerd worden. Daarnaast moet het ook mogelijk zijn dat peer-to-peer uitsluitend via het lokale netwerk gaat, wanneer mogelijk. Ik heb mijzelf nog niet in de details verdiept, dus ik kan ernaast zitten. Het is dan ook nog een testopstelling.

Ik heb een server ingesteld als 'sending only' en de ander als 'receiving only'. Volgens mij is het prima mogelijk om veel meer servers aan elkaar te koppelen. Je kunt via een eenvoudige web-interface mappen/shares aanmaken en die delen met andere Syncthing instanties op andere servers dmv een key.

Wel wil ik nog kijken wat de performance verschillen zijn met 'gewoon' rsync en ben ik benieuwd hoe goed dit werkt over een langere termijn (je weet maar nooit).

[Hero of Time]

Wat zijn de exacte voordelen om voor Syncthing te kiezen, als de servers al fysiek en logisch naast elkaar staan? Waarom zou je daar dan nog eens internet sync bij willen hebben? Synchronisatie tussen de twee machines wil je zo veel mogelijk gescheiden houden van de rest van je verkeer.

Ik snap je keuze daarom niet als je het vergelijkt met andere mogelijkheden, zoals drbd en rsync of unison.

[Waxyen]

De eisen van de servers zijn een beetje veranderd. Daarnaast is er tijd ontstaan waarin ik verschillende dingen kan testen. Nu moet er ook een remote-sync gedaan worden. Dit had ik wel even moeten vermelden voor de duidelijkheid, excuses.

Edit:
De servers staan ook weleens naast elkaar, maar niet altijd. Een van de servers is portable.

[ Voor 17% gewijzigd door Waxyen op 28-11-2019 16:07 ]

[xares]

Ik heb in het verleden wel eens DRBD gedraaid op 2 systemen en dan met OpenVZ (soort software virtualisatie). Draaide prima. Alleen je moet wel weten wat je doet als je een splitted-brain situatie krijgt.

RSYNC lijkt mij wat minder geschikt omdat het niet realtime is?