Bekijk Volledige Versie : Hoe stabiel, betrouwbaar en veilig is DRBD ?
webspecialist
25/06/07, 12:22
Ik overweeg om op korte termijn een faillover situatie op te stellen met 2 servers met behulp van DRBD en Heartbeat.
Server 1 = actief
Server 2 = passief
Server 1 valt uit, server 2 wordt actief.
Eén partitie bevat dan alle data (inc. mySQL) icm drbd.
Echter:
Als er iets misgaat met het filesysteem (DRBD) dan gebeurd dat ook op de failover met alle gevolgen van dien. Dus stel MySQL raakt corrupt, dan is dat in de faillover ook het geval.
Vraag:
Hoe betrouwbaar is DRBD?
http://www.google.nl/search?hl=nl&q=drbd+bug&btnG=Google+zoeken&meta=
lees het zelf.
Voor degene die me negatieve reputatie gegeven heeft omdat het te makkelijk is, heeft deze zin om te onderbouwen waarom hij/zij mij deze negatieve reputatie gegeven heeft omdat deze te makkelijk zou zijn?
Mijn eigen ervaringen zijn dat DRBD goed draait zolang je je systemen goed draaien en juist in geval van calamiteiten en problemen ook DRBD het wel eens af laat weten...
Zelf in een testopstelling een aantal weken 2 MySQL servers in master-slave met DRBD ertussen gehad, werkte opzich prima ook met uit/aanzetten.
maar op moment dat server1 uitging en 10 mins later server2 en ze dan niet in de volgorde server2 / server 1 weer aangingen dan was het mis...
webspecialist
25/06/07, 15:46
lees het zelf.
Voor degene die me negatieve reputatie gegeven heeft omdat het te makkelijk is, heeft deze zin om te onderbouwen waarom hij/zij mij deze negatieve reputatie gegeven heeft omdat deze te makkelijk zou zijn?
Bedankt voor je reactie, maar ik vraag juist naar ervaringen.
Graag ook even on topic blijven, alvast bedankt!
Mijn eigen ervaringen zijn dat DRBD goed draait zolang je je systemen goed draaien en juist in geval van calamiteiten en problemen ook DRBD het wel eens af laat weten...
Zelf in een testopstelling een aantal weken 2 MySQL servers in master-slave met DRBD ertussen gehad, werkte opzich prima ook met uit/aanzetten.
maar op moment dat server1 uitging en 10 mins later server2 en ze dan niet in de volgorde server2 / server 1 weer aangingen dan was het mis...
Bedankt voor je reactie. Mijn huidige leverancier wil mij op dit moment ook niet meer ondersteunen met DRBD. Hij geeft aan dat hij het niet 100% stabiel kan krijgen of enigszins betrouwbaar. Lekker is dat als je eenmaal een weg ingeslagen bent. Maar goed... Ik vraag mij dus af of het een geval van kennis of van bugs is.
Hoor graag nog meer meningen/ervaringen, alvast bedankt!
Mijn ervaring:
Ik heb een HA failover gedraaid met DRBD, eigenlijk in het begin zonder al te veel problemen, tot dat er veel data op stond en we een failover test gingen uitvoeren, dit hadden we blijkbaar maar niet moeten doen, want we kregen errors dat unsynced was en kon het niet meer resyncen ivm met teveel data, errors noem maar op.
Daarom raad ik drbd af. Zoals je ook in de google url gaf, zijn er veel problemen daarin relevant voor het wel of niet gebruiken van de tool.
Zijn er dan andere alternative, wat ik veel hoor is Rsync. Zijn er SANS die redundant kunnen draaien?
Ja hoor,
NetApp, EMC, HP Eva, Hitachi, Equalogic.
Waarbij netapp mijn voorkeur heeft :)
Totdat EMC bij een bancaire instelling schijt heeft aan alle procedures en tijdens een maintenance window van de bank ineens besluit om onaangekondigd een kritieke update te gaan uitvoeren op het SAN waardoor alles, maar dan ook ALLES dood gaat.
Ik hoor hier een ervaring :D Eigenlijk is het heel simpel, datacorruptie kun je in principe niet voorkomen. Kijk je bijvoorbeeld naar MySQL, dan heb je inderdaad het probleem dat data corrupt kan raken. De vraag is echter of je het systeem hiervoor kunt gebruiken. Als een MySQL tabel corrupt raakt, dan kan dat verschillende oorzaken hebben. Op het moment dat de oorzaak softwarematig is, dan kun je redundant je hardware uitvoeren, echter schiet je daar niets mee op.
Hier zul je dus iets anders op moeten bedenken. Ik ken voorbeelden genoeg, waarbij complete defecte schijven gesynct werden. Het belang van een goede backup kan ik daarbij alleen nog maar benadrukken.
Ik heb een aantal zaken gehoord, als in het voorbeeld van phreak dat bij zware belasting de synchronisatie stuk kan lopen. Ik durf niet te zeggen of dat veroorzaakt werd door netwerk, disk i/o of de software. Uiteraard is kun je een testtool gebruiken om eens flink wat data te testen.
Almar heeft gelijk, mits je het niet in een productie omgeving doet, dat gaat een behoorlijke killer worden, vergeet niet dat het om grotere data is, dus je zult flink aan de gang moeten.
@Sander-: dat heb ik nog niet meegekregen.
Al met al, mijn tip, nogmaals, wat ik zelf ook doe bij mijn eigen cluster, is maak 1 x een full rsync naar de backup server, zonder dat er een service draait (apache/mysql/ftp), maak elk uur een incremental, desnoods met een nice erachteraan, zo weet je zeker, dat je elk uur een sync hebt, en het is beter dan een uur achter lopen met je data dan AL je data kwijt zijn.
Ik hoor hier een ervaring :D Eigenlijk is het heel simpel, datacorruptie kun je in principe niet voorkomen.
Het is wel te voorkomen, maar dan moet je geen synchronize mirror doen, maar asynchronize, waar bij de je accepteert dat je een tijdseenheid aan data verliest.
Dat zijn keuzes die gemaakt worden, snel up-and-running met een xx periode aan data verlies, of volledige recovery, geen dataverlies, maar wel (hoogst waarschijnlijk) productiviteits verlies door het niet beschikbaar hebben van systemen.
webspecialist
26/06/07, 09:38
Het is wel te voorkomen, maar dan moet je geen synchronize mirror doen, maar asynchronize, waar bij de je accepteert dat je een tijdseenheid aan data verliest.
Dat zijn keuzes die gemaakt worden, snel up-and-running met een xx periode aan data verlies, of volledige recovery, geen dataverlies, maar wel (hoogst waarschijnlijk) productiviteits verlies door het niet beschikbaar hebben van systemen.
Ik denk dat een combinatie van deze 2 het beste is. Dus een faillover situatie, waarbij altijd nog naar een externe locatie wordt gebackuped. Maar in de praktijk dus wat lastiger doordat de kans groot is dat data corrupt raakt (DRBD).Ik denk dat een sync van ieder uur echter te veel belasting met zich mee gaat brengen. Ik praat hier namelijk over een shared hosting oplossing.
Ik zit nu zelf te denken aan een RAID5 NAS, waarbij 's nachts een incrementele backup wordt gemaakt naar een ander datacenter. Het DRBD verhaal laat ik waarschijnlijk maar met rust. Ik heb er nu al zo veel problemen mee gehad en over gelezen.
Andere oplossingen zijn mijn inziens nog te onbekend of kostbaar om te implementeren.
Het is wel te voorkomen, maar dan moet je geen synchronize mirror doen, maar asynchronize, waar bij de je accepteert dat je een tijdseenheid aan data verliest.
Ik doelde bijvoorbeeld op een corrupte MySQL tabel. Ongeacht de wijze van syncen, ben je hier toch corrupte data aan het syncen.
Ik doelde bijvoorbeeld op een corrupte MySQL tabel. Ongeacht de wijze van syncen, ben je hier toch corrupte data aan het syncen.
Dat snap ik, maar dat kun je idd oplossen door ook je database nog te dumpen.
Maar corrupte data? Betekend dat verkeerde user input?
Dat zou je van te voren op moeten lossen.
Dat zou je van te voren op moeten lossen.
Nou ja de oorzaak hiervan kan echt van alles zijn, alleen staan weinig mensen hierbij stil. Backup is belangrijk, maar data-integrity ook.