Bekijk Volledige Versie : Lokale backups mislukken (HD stuk?)
guidonline
25/08/12, 00:21
Ik heb sinds een paar weken een nieuwe server in het DC hangen voor virtuele servers met 2 schijven in raid 1 en 1 losse HD.
2 x Western Digital RE4 1TB, 7200rpm, 64 mb cache (beide schijven op een 6Gbit sata poort) - hier draaien de VM's + OS op
1 x Western Digital Eco Green 2TB, 5400rpm, 64 mb cache (schijf op een 3Gbit sata poort) - Schijf voor backups
Het systeem draait prima de virtuele servers hebben prima performance en backups naar een server in een ander DC (via een samba share) gaan ook prima. De performance gaan alleen een beetje omlaag (en das logisch natuurlijk). Maar zo gauw ik lokaal back-ups maak naar de WD eco Green schijf wordt er 4 tot 7 GB weg geschreven en daarna stopt de backup loopt de server load op en crasht de hele server.
Soms is de server nog te redden door snel het back-up process te killen. Ik heb geen idee, misschien is de HD wel stuk, maar voor ik naar het DC rij om die te vervangen zou ik graag van jullie willen weten of het ook iets anders zou kunnen zijn. Het blijft een slome 5400rpm eco green schijf, maar voor een paar backups zou dat toch niet mogen deren?
De backups draai ik via Proxmox en VZDump.
guidonline
25/08/12, 00:29
Heb geprobeerd een speedtest file van 50GB binnen te halen op de HD en ook dan crasht alles.
Wat zegt de S.M.A.R.T. tool voor deze disk?
En welk filesystem word er gebruikt op die disk?
patrickekkel
25/08/12, 08:32
Mischien een idee om eens wat snellere schijfen te gaan gebruiken.
Wat betreft een productie server met sata schijven ... Daar zal ik maar niks over zeggen men weet hoe ik daar over denk en met mij meerdere.
Maar knal er in iedergeval die green disk uit en vervang die voor een andere sata disk het liefst een enterprice disk.
guidonline
25/08/12, 09:31
De S.M.A.R.T. check passed. M'n filesystem is gewoon Ext3.
root@proxmox:~# smartctl -a /dev/sdc
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Device Model: WDC WD20EARX-32PASB0
Serial Number: WD-WCAZAE153936
Firmware Version: 51.0AB51
User Capacity: 2,000,398,934,016 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 8
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Sat Aug 25 09:29:15 2012 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x80) Offline data collection activity
was never started.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (39600) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off supp ort.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 255) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x3035) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_ FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 2
3 Spin_Up_Time 0x0027 181 174 021 Pre-fail Always - 5908
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 63
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 256
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 61
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 44
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 193
194 Temperature_Celsius 0x0022 121 117 000 Old_age Always - 29
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
root@proxmox:~# smartctl -a /dev/sdc
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Device Model: WDC WD20EARX-32PASB0
Serial Number: WD-WCAZAE153936
Firmware Version: 51.0AB51
User Capacity: 2,000,398,934,016 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 8
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Sat Aug 25 09:30:45 2012 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x80) Offline data collection activity
was never started.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (39600) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 255) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x3035) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 2
3 Spin_Up_Time 0x0027 181 174 021 Pre-fail Always - 5908
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 63
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 256
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 61
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 44
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 194
194 Temperature_Celsius 0x0022 120 117 000 Old_age Always - 30
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
Vanwege de prijs hou ik het wel bij SATA schijven zeker omdat de performance van het systeem verder prima zijn. Maar de Eco Green wil ik inderdaad graag gaan vervangen. Kan iemand me een 2TB SATA schijf aanraden?
patrickekkel
25/08/12, 09:44
http://gistron.nl/info/40961/info.html
Mischien een idee om eens wat snellere schijfen te gaan gebruiken.
Nog niet helemaal wakker :)
Voor casual backups zijn deze SATA schijven normaal prima.
Wij hadden vergelijkbare problemen met met trage NFS disk.
Heb je toevallig in de server een SATA poort op het moederbord, ipv raid kaart.. zodat je naar een "ander" kanaal backupt?
guidonline
25/08/12, 17:26
Hmm ander kanaal zou kunnen. Maar alle 3 de schijven zitten op het moederbord (software raid). We zit de 2e schijf op een 3gbit poort en de andere 2 op een 6gbit poort. Voor SATA schijven maakt 3gbit of 6gbit wellicht niet zoveel uit, en dan kan ik ook alle schijven op hetzelfde blok prikken (allen op 3 gbit). Of mag dit niet uitmaken?
Dit zou niet mogen uitmaken. De SATA bus is veel sneller dan de SATA schijven die je er aan hangt. Je zou eens kunnen testen met een hele andere schijf in plaats van die backup disk. Als het dan wel werkt, dan heb je simpelweg een defecte disk. Is er dan ook een probleem, dan zou het wel eens aan je OS of moederbord kunnen liggen. Dergelijke opstellingen heb ik ook een paar draaien, nooit problemen mee gehad.
Heb geprobeerd een speedtest file van 50GB binnen te halen op de HD en ook dan crasht alles.
Die hoef je toch niet van buiten te halen ?
dd if=/dev/zero of=/mnt/backupdisk/testfile.bin bs=1M count=4096
(dan heb je 4096*1M = 4G testfile van nullen, en gelezen met de echt maximale snelheid).
Neem count=16384 voor 16G.
Maar die oplopende load en crashende server daarna zou niet moeten. Een wat langzamere harddisk mag niet dat effect hebben, die is gewoon alleen maar wat langzamer.
Ik kan niet zeggen of het je disk is die kapot is , of het mobo/controller, of misschien de driver van de kernel , maar ergens is er iets niet goed. Heb je iets in dmesg van het moment dat het misgaat ?
Je kunt een andere schijf proberen, of de disken omprikken op een andere controller.
De sustained throughput (wat de kop naar de schijf kwijt kan als die achter elkaar kan doorschrijven) zal enkele tientallen MB's per seconde zijn. Dus een paar honderd megabit/seconde . Veel minder dus dan 3 Gbit/sec .
Yourwebhoster
25/08/12, 18:49
Ik heb volgens mij nog een aantal 5400 RPM 2TB disks in Serverius liggen (ooit uit een nas gesloopt). Die kan je evt wel lenen.
wesneijertje
25/08/12, 19:23
en als je nu voor de grap eens meer dan bijvoorbeeld 10GB wegschrijft naar de schijf (gewone data).
mooie test om te kijken of het softwarematig is of dat het ergens anders aan ligt (mobo ofzo).
Installeer het programma atop en kijk eens live mee terwijl het mis gaat. Je kunt dan zien of de disken het druk hebben of een bepaald programma of iets.
guidonline
26/08/12, 00:08
root@proxmox:/backup/dump# dd if=/dev/zero of=/backup/testfile.bin bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 130.598 s, 32.9 MB/s
Ik draai nu een lokale test 4 GB schrijven was geen probleem maar wel erg sloom. Ik ga nu een test draaien met 50GB en kijken hoe dat loopt.
Het rare is dat ik er ok al een keer een back-up van 60 GB en 80 GB op heb opgeslagen en toen was er niks aan de hand. Het lijkt dus soms wel goed te gaan (sorry was wel belangrijk om te melden). Dus dat zou dan lijkt me heel goed een harddisk defect zijn.
@Yourwebhostereu Dat zou geweldig zijn. Ik heb zojuist een Western Digital Black RE4 7200rpm besteld van 2TB (als het niet nodig is komt die wel van pas in een andere machine) maar heb geen idee of ik die ptijd binnen heb. Ik ga namelijk dinsdag naar het DC (want dan kan m'n coloboer me erin laten heb nog geen eigen pasje). Weet niet of jij dan aanwezig bent? Of dat je toegang hebt tot dezelfde ruimte zodat je er 1 kan leggen in het rack?
guidonline
26/08/12, 00:53
root@proxmox:/backup/dump# dd if=/dev/zero of=/backup/testfile.bin bs=1M count=50096
50096+0 records in
50096+0 records out
52529463296 bytes (53 GB) copied, 2620.77 s, 20.0 MB/s
Ook het schrijven van een 50GB file ging helemaal goed. Ook dit ging heel erg langzaam. Wat me opviel in atop is dat de disk steeds even stil stond voor een paar seconden en daarna weer verder ging.
Zou het kunnen dat op zoon moment VZDump vastloopt omdat hij even niet verder kan schrijven?
Die kans is heel groot! Je kunt nog proberen in VZDUMP.conf de bandbreedte aan te passen, maar dat geeft op langer termijn problemen.
Yourwebhoster
26/08/12, 10:03
@Yourwebhostereu Dat zou geweldig zijn. Ik heb zojuist een Western Digital Black RE4 7200rpm besteld van 2TB (als het niet nodig is komt die wel van pas in een andere machine) maar heb geen idee of ik die ptijd binnen heb. Ik ga namelijk dinsdag naar het DC (want dan kan m'n coloboer me erin laten heb nog geen eigen pasje). Weet niet of jij dan aanwezig bent? Of dat je toegang hebt tot dezelfde ruimte zodat je er 1 kan leggen in het rack?
Als je hier een ticket kan inschieten met welk rack en suite dan zal ik kijken wat mogelijk is: https://yourwebhoster.eu/contact/
T. Verhaeg
26/08/12, 10:26
@Yourwebhostereu Dat zou geweldig zijn. Ik heb zojuist een Western Digital Black RE4 7200rpm besteld van 2TB (als het niet nodig is komt die wel van pas in een andere machine) maar heb geen idee of ik die ptijd binnen heb. Ik ga namelijk dinsdag naar het DC (want dan kan m'n coloboer me erin laten heb nog geen eigen pasje). Weet niet of jij dan aanwezig bent? Of dat je toegang hebt tot dezelfde ruimte zodat je er 1 kan leggen in het rack?
Als je die bij een goede webshop besteld hebt dan zou je die nog dinsdag binnen moeten hebben. Er van uitgaande dat je 's avonds gaat zal die wel binnenkomen, en ik zou zelf kijken om die te gebruiken. De schijf van YWH is ook 'maar' 5.4k RPM. Dan had ik toch zelf liever meteen de goede schijf erin gezet zodat je je backups gewoon goed op orde hebt, en snel(ler) terug kunt zetten als dat noodzakelijk blijkt. Lezen en schrijven vanaf een 7.2k rpm disk gaat natuurlijk gewoon sneller.
patrickekkel
26/08/12, 10:52
@guidonline als je eerder in serverius moet zijn kan ik je ook helpen als het moet.
Moet enkel Huib toestemming geven om jou naar binnen te laten.
Yourwebhoster
26/08/12, 11:32
Als je die bij een goede webshop besteld hebt dan zou je die nog dinsdag binnen moeten hebben. Er van uitgaande dat je 's avonds gaat zal die wel binnenkomen, en ik zou zelf kijken om die te gebruiken. De schijf van YWH is ook 'maar' 5.4k RPM. Dan had ik toch zelf liever meteen de goede schijf erin gezet zodat je je backups gewoon goed op orde hebt, en snel(ler) terug kunt zetten als dat noodzakelijk blijkt. Lezen en schrijven vanaf een 7.2k rpm disk gaat natuurlijk gewoon sneller.
Voor backup is een 5400RPM prima, deze schijven presteren ook prima en zijn stabiel. Enige kanttekening is dat het niet enterprise schijven zijn, maar om te testen wat het probleem zou kunnen zijn (de harde schijf of iets anders) lijkt mij dat dit voldoet.
Guido, even een kanttekening mbt backups. Wat als deze harde schijf kapot gaat; dan heb je geen backups meer. En backups wil je eigenlijk niet in dezelfde server hebben zitten en het liefste ook nog op een andere locatie. Denk maar aan het probleem dat de server zelf compleet offline gaat, dan kan je er niks meer mee tenzij je op locatie de hardeschijf gaat overplaatsen. Ik zou zelf gaan voor een RAID setup voor je backups gaan (backups zijn je laatste redmiddel en daar moet je eigenlijk niet op bezuinigen).
.. Ik zou zelf gaan voor een RAID setup (backups zijn je laatste redmiddel en daar moet je eigenlijk niet op bezuinigen).
In de 1e regel van de post van OP staat:
Ik heb sinds een paar weken een nieuwe server in het DC hangen voor virtuele servers met 2 schijven in raid 1 en 1 losse HD.
Maarre, je hebt gelijk dat externe backups wenselijk zijn.
Yourwebhoster
26/08/12, 11:41
In de 1e regel van de post van OP staat:
Maarre, je hebt gelijk dat externe backups wenselijk zijn.
In die post staat ook:
2 x Western Digital RE4 1TB, 7200rpm, 64 mb cache (beide schijven op een 6Gbit sata poort) - hier draaien de VM's + OS op
1 x Western Digital Eco Green 2TB, 5400rpm, 64 mb cache (schijf op een 3Gbit sata poort) - Schijf voor backups
Ik mag aannemen dat TS niet een 2TB consumenten schijf icm een 1TB enterprise schijf gebruikt in RAID 1;)
Edit: Heb mijn post aangepast, het was wat onduidelijk wellicht.
Ahh.. OK, RAID op je backups is geen overbodige luxe. Ik dacht inderdaad dat je bedoelde dat hij zijn OS/DATA onder RAID moest draaien. Dan heb ik niks gezegd ;)
guidonline
26/08/12, 14:20
Dat de back-ups op dezelfde server komen is maar tijdelijk. Er komt binnen 2 maanden een 2e server in ee andere rack waarnaar ik dan intern alles ga back-uppen. Die server gaat op zijn beurt weer naar deze server backup-pen. Maar dit is een noodoplossing, omdat ik al wel backups wil hebben zolang die machine er nog niet is.
Ik heb hoe raar het ook is ineens backups gemaakt de gelukt zijn.
VMID NAME STATUS TIME SIZE FILENAME
107 www.xxxxxx.nl OK 00:46:10 20.00GB /backup/dump/vzdump-qemu-107-2012_08_26-06_30_02.tar
110 relay.xxxxxx.nl OK 01:51:04 50.00GB /backup/dump/vzdump-qemu-110-2012_08_26-07_16_21.tar
TOTAL 02:37:23 70.00GB
Detailed backup logs:
vzdump 110 107 --quiet 1 --mailto xxxxx@xxxxxxx.nl --mode snapshot --node proxmox --storage backup
107: Aug 26 06:30:02 INFO: Starting Backup of VM 107 (qemu)
107: Aug 26 06:30:02 INFO: status = running
107: Aug 26 06:30:04 INFO: backup mode: snapshot
107: Aug 26 06:30:04 INFO: bandwidth limit: 1000000 KB/s
107: Aug 26 06:30:04 INFO: ionice priority: 7
107: Aug 26 06:30:05 INFO: Logical volume "vzsnap-proxmox-0" created
107: Aug 26 06:30:05 INFO: creating archive '/backup/dump/vzdump-qemu-107-2012_08_26-06_30_02.tar'
107: Aug 26 06:30:05 INFO: adding '/backup/dump/vzdump-qemu-107-2012_08_26-06_30_02.tmp/qemu-server.conf' to archive ('qemu-server.conf')
107: Aug 26 06:30:05 INFO: adding '/dev/local/vzsnap-proxmox-0' to archive ('vm-disk-virtio0.raw')
107: Aug 26 07:15:46 INFO: Total bytes written: 21474839040 (7.47 MiB/s)
107: Aug 26 07:15:51 INFO: archive file size: 20.00GB
107: Aug 26 07:16:12 INFO: Finished Backup of VM 107 (00:46:10)
110: Aug 26 07:16:24 INFO: Starting Backup of VM 110 (qemu)
110: Aug 26 07:16:24 INFO: status = running
110: Aug 26 07:17:10 INFO: backup mode: snapshot
110: Aug 26 07:17:10 INFO: bandwidth limit: 1000000 KB/s
110: Aug 26 07:17:10 INFO: ionice priority: 7
110: Aug 26 07:17:34 INFO: Logical volume "vzsnap-proxmox-0" created
110: Aug 26 07:17:34 INFO: creating archive '/backup/dump/vzdump-qemu-110-2012_08_26-07_16_21.tar'
110: Aug 26 07:17:34 INFO: adding '/backup/dump/vzdump-qemu-110-2012_08_26-07_16_21.tmp/qemu-server.conf' to archive ('qemu-server.conf')
110: Aug 26 07:17:34 INFO: adding '/dev/local/vzsnap-proxmox-0' to archive ('vm-disk-ide0.raw')
110: Aug 26 09:07:08 INFO: Total bytes written: 53691288064 (7.79 MiB/s)
110: Aug 26 09:07:08 INFO: archive file size: 50.00GB
110: Aug 26 09:07:25 INFO: Finished Backup of VM 110 (01:51:04)
Wel heel traag.. Maargoed wel gelukt...
Heb de bandbreedte wat omlaag geschroeft inderdaad (maar kan ook zijn dat de schijf bad sectors heeft en dat hij die nu niet beschrijft omdat daar die test bestanden op staan, ik brainstorm maar iets). Ik heb in elk gevak nu een Western Digital Black schijf besteld met gelijke performance als de RAID configuratie schijven. Die gaat er als die binnen is dinsdag in.
@patrickekkel Eerder is niet nodig want dan heb ik nog geen nieuwe schijf. Dinsdag krijg ik eindelijk m'n eigen pasje. Ik kon niet onder kantoortijden vandaar dat het lastig werd, maar als goed is is er dinsdag avond iemand van Serverius aanwezig.
root@proxmox:/backup/dump# dd if=/dev/zero of=/backup/testfile.bin bs=1M count=50096
50096+0 records in
50096+0 records out
52529463296 bytes (53 GB) copied, 2620.77 s, 20.0 MB/s
Ook het schrijven van een 50GB file ging helemaal goed. Ook dit ging heel erg langzaam. Wat me opviel in atop is dat de disk steeds even stil stond voor een paar seconden en daarna weer verder ging.
Zou het kunnen dat op zoon moment VZDump vastloopt omdat hij even niet verder kan schrijven?
Dat is wel veel trager dan zou moeten voor dit type test.
De spec van een WD20EARS (green, 2TB, 3Gb/s sata) claimt 110 MB/sec sustained.
Maar als je geen andere accesses hebt op een filesysteem, en de server is niet enorm druk zou je daar wel bij in de buurt moeten komen als je met dd van /dev/null leest.
Desondanks zou een backup programma niet moeten vastlopen als een io subsysteem trager is dan verwacht, laat staan dat een hele server ervan vastloopt.
Spijtig genoeg ben je niet de enige met dit probleem, lijkt een kernel probleem te zijn wat al even speelt in combo met Proxmox.
(Zoek maar eens op hun forum). VZDUMP schiet volledig in de stress als ie te weinig ruimte krijgt om te schrijven.
Zet de limit eens op 10 MB/s (standaard geloof ik)
guidonline
26/08/12, 22:52
De limiet ga ik eens op 10 en 20 zetten en het nogmaals proberen. Ik moet zeggen dat er toch al aardig wat back-ups gelukt waren vandaag maar toch. Ik vond verder:
Change the Linux default IO scheduler to "deadline"
You can do this by adding "elevator=deadline" to /boot/grub/menu.lst, at the end of your running kernel line, so it looks something like this:
kernel /vmlinuz-2.6.32-6-pve root=/dev/mapper/pve-root ro quiet elevator=deadline
More info here:
http://www.serverwatch.com/tutorials/article.php/3819446/Selecting-and-Tuning-a-Scheduler.htm
This will magically turn your server back to working normal during vzdump backups (and also much more responsive during any kind of heavy disk IO), regardless of using a one-disk setup or a 8-disk RAID array.
It's a shame Proxmox still uses the lame CFQ scheduler when the global Linux server community is starting to agree that CFQ is not suitable for server environments.
Dat ga ik dus eerst proberen...
guidonline
26/08/12, 23:18
Ik heb nu de elevator op deadline staan voor de backup disk (sdc). Moet en is het ook veilig dit voor sda en sdb te doen? Of moet het voor de raid array gedaan worden (md5). Dit was me namelijk niet helemaal duidelijk en wil niet m'n systeem straks onbereikbaar hebben natuurlijk....
De limiet ga ik eens op 10 en 20 zetten en het nogmaals proberen. Ik moet zeggen dat er toch al aardig wat back-ups gelukt waren vandaag maar toch. Ik vond verder:
Change the Linux default IO scheduler to "deadline"
You can do this by adding "elevator=deadline" to /boot/grub/menu.lst, at the end of your running kernel line, so it looks something like this:
kernel /vmlinuz-2.6.32-6-pve root=/dev/mapper/pve-root ro quiet elevator=deadline
More info here:
http://www.serverwatch.com/tutorials/article.php/3819446/Selecting-and-Tuning-a-Scheduler.htm
This will magically turn your server back to working normal during vzdump backups (and also much more responsive during any kind of heavy disk IO), regardless of using a one-disk setup or a 8-disk RAID array.
It's a shame Proxmox still uses the lame CFQ scheduler when the global Linux server community is starting to agree that CFQ is not suitable for server environments.
Dat ga ik dus eerst proberen...
Ik betwijfel of het gaat helpen.
IO schedulers verdelen IO capaciteit als er door veel processen IO gevraagd wordt.
Als er weinig of geen andere processen waren die IO wilden op die backup disk bij die veel te trage 'dd' write test (of tijdens een vzdump) dan verwacht ik geen verschil van een andere scheduler.
guidonline
30/08/12, 22:39
Sinds ik de evalator op deadline heb staan maak ik al ruim 4 dagen nu probleemloos back-ups. Ongeveer met 40 mb/s wat heel schappelijk is met schijven waar ook al VPS'sen vanaf draaien. Dit is dus wel degelijk de oplossing met VZDump en een Proxmox kernel..;-) topic mag dicht van mij!
Ooh ja de schijf is inmiddels nog niet vervangen. Post kwam pas om half 7 terwijl TNT beweerd voor 5 uur te leveren (maar sinds de nieuwe bezorger dus niet meer). Dat doe ik dan maar volgende week...
Western digital greens hebben heel erg last van trillingen, als je server trilt (fans ed, of rack) gaat de performance heel erg achteruit, soms zo erg dat de server crashed. Je zou eens kunnen proberen de hd testen als je hem los buiten de server hebt
Succes
dennis0162
31/08/12, 12:34
Klopt inderdaad, maar buiten dat zijn dat sowieso klote schijven ook voor in je desktop.
Western digital greens hebben heel erg last van trillingen, als je server trilt (fans ed, of rack) gaat de performance heel erg achteruit, soms zo erg dat de server crashed. Je zou eens kunnen proberen de hd testen als je hem los buiten de server hebt
Succes
Volgens mij zijn die Green ook totaal niet bedoeld voor servers. Hier zitten namelijk enkele "groene" maatregelen op waar je totaal niet op zit te wachten.
Volgens mij zijn die Green ook totaal niet bedoeld voor servers. Hier zitten namelijk enkele "groene" maatregelen op waar je totaal niet op zit te wachten.
Die kan je eruit patchen met een nieuwe firmware, waardoor hij niet meer elke 4? seconden de koppen parkeert en je Load_Cycle_Count oploopt (bij 200k of meer gaan ze vaak stuk)
Ook zit je met de alinging van partities wat standaart niet lekker gaat (ging?)
Maar al met al niet aan te raden in een server
Die kan je eruit patchen met een nieuwe firmware, waardoor hij niet meer elke 4? seconden de koppen parkeert en je Load_Cycle_Count oploopt (bij 200k of meer gaan ze vaak stuk)
Ook zit je met de alinging van partities wat standaart niet lekker gaat (ging?)
Maar al met al niet aan te raden in een server
Maar is alle extra tijd die je daar in steekt het wel waard? Hoeveel goedkoper is een Green Edition? 10 euro misschien