[2003] defragmenteren storage server icm iSCSI

[Grolsch]

Hallo Mensen,

Wij maken hier gebruik van een Microsoft Windows Storage server 2003
op deze server draait wintarget iSCSI met een aantal virtuele iSCSI discs voor een aantal servers (Exchange / SQL / andere database).

Op de storage server is een RAID 10 disk gedefinieert met totaal 682GB schijfruimte.
Deze schijf host dus de virtuele iSCSI schijven.

Nu is de schijf van 682GB aardig gefragmenteerd zoals je hieronder kunt zien.

code:

Volume NASDATA (E:)
    Volume size                                = 683 GB
    Cluster size                               = 4 KB
    Used space                                 = 444 GB
    Free space                                 = 238 GB
    Percent free space                         = 34 %

Volume fragmentation
    Total fragmentation                        = 21 %
    File fragmentation                         = 43 %
    Free space fragmentation                   = 0 %

File fragmentation
    Total files                                = 666,574
    Average file size                          = 902 KB
    Total fragmented files                     = 40,651
    Total excess fragments                     = 1,410,388
    Average fragments per file                 = 3.11

Pagefile fragmentation
    Pagefile size                              = 0 bytes
    Total fragments                            = 0

Folder fragmentation
    Total folders                              = 90,573
    Fragmented folders                         = 1,860
    Excess folder fragments                    = 5,808

Master File Table (MFT) fragmentation
    Total MFT size                             = 899 MB
    MFT record count                           = 778,030
    Percent MFT in use                         = 84 %
    Total MFT fragments                        = 10

--------------------------------------------------------------------------------
Fragments       File Size       Most fragmented files
263,880         97.66 GB        \....
120,159         19.53 GB        \...
32,073          1.96 GB         \...
27,970          1.82 GB         \...
19,184          1.50 GB         \...
15,701          586 MB          \...
14,549          267 MB          \...
10,729          677 MB          \...
10,385          649 MB          \...
10,239          649 MB          \...
9,013           562 MB          \...
8,795           583 MB          \...
8,371           22.46 GB       ....
7,601           642 MB          \....
7,098           151 MB          \...
6,861           128 MB          \....
6,602           148 MB          \....
6,530           412 MB          \...
6,528           240 MB          ...
6,442           344 MB          \...
6,312           645 MB          \.....
6,197           387 MB          \.
5,718           355 MB          \.
5,538           346 MB          \.
5,489           343 MB          \.
5,033           252 MB          .....
4,994           320 MB          \.
3,695           152 MB          \....
3,639           343 MB          .
3,236           393 MB          .....

de shit is alleen dat als ik deze schijf ga defragmenteren er een dusdanige load op het systeem komt, dat m'n iSCSI disks kuren gaan vertonen en de koppeling verbreken waardoor dus onder andere m'n exchange en SQL over de zeik gaan.

Ook kan ik in storage server 2003 een defragmentatie schedulen, maar ook al schedule ik het 's nachts, m'n servers verbreken de verbinding met hun iSCSI schijf waardoor weer problemen ontstaan.

Iemand van jullie een idee hoe dit op te lossen

[Verwijderd]

sorry hoor maar mij is ALTIJD geleerd ga NOOIT een server defragmeteren, niet echt slim lijkt me

[Gunner]

Verwijderd schreef op woensdag 03 januari 2007 @ 15:41:
sorry hoor maar mij is ALTIJD geleerd ga NOOIT een server defragmeteren, niet echt slim lijkt me

En gaven ze daar ook nog een reden voor op?

[MAX3400]

Verwijderd schreef op woensdag 03 januari 2007 @ 15:41:
sorry hoor maar mij is ALTIJD geleerd ga NOOIT een server defragmeteren, niet echt slim lijkt me

Ik heb altijd geleerd dit soort uitspraken met een dikke korrel zout te nemen...

@Topic-starter: ondanks dat de verbinding wordt verbroken, loopt dan de defrag ook niet? Heb je WinTarget zelf al gesproken over dit probleem? Kan je niet iets defraggen via het cabinet zelf?

[alt-92]

Verwijderd schreef op woensdag 03 januari 2007 @ 15:41:
sorry hoor maar mij is ALTIJD geleerd ga NOOIT een server defragmeteren, niet echt slim lijkt me

.....en dan krijg je uiteindelijk een FS wat er dus zoals in de TS uitziet.

Lijkt me ook niet echt wenselijk.
Wij defraggen 1x per week om en om de SAN disks @ 450GB via een ScheduledTask.
zaterdag de een, zondag de volgende, enzovoort enzo.

Scheelt een boel als je dat al from scratch doet.

[Grolsch]

Verwijderd schreef op woensdag 03 januari 2007 @ 15:41:
sorry hoor maar mij is ALTIJD geleerd ga NOOIT een server defragmeteren, niet echt slim lijkt me

mij is altijd geleerd alleen maar nuttig te reageren op een post met onderbouwing
natuurlijk is het absoluut NIET wenselijk dat 1 van mijn database iSCSI disks verspreid is over 263,880 plekken op je SAN, dat kost performance

MAX3400 schreef op woensdag 03 januari 2007 @ 15:45:
[...]

Ik heb altijd geleerd dit soort uitspraken met een dikke korrel zout te nemen...

@Topic-starter: ondanks dat de verbinding wordt verbroken, loopt dan de defrag ook niet? Heb je WinTarget zelf al gesproken over dit probleem? Kan je niet iets defraggen via het cabinet zelf?

de defrag loopt wel, maar zodra al mijn stores er opdat moment uitklappen weet ik niet hoe snel ik die defrag moet cancelen
Ik heb er nog niet over gesproken met wintarget, ik zal eens op hun website kijken.

alt-92 schreef op woensdag 03 januari 2007 @ 17:34:
[...]

.....en dan krijg je uiteindelijk een FS wat er dus zoals in de TS uitziet.

Lijkt me ook niet echt wenselijk.
Wij defraggen 1x per week om en om de SAN disks @ 450GB via een ScheduledTask.
zaterdag de een, zondag de volgende, enzovoort enzo.

Scheelt een boel als je dat al from scratch doet.

ik wil het wel schedulen (zelfs een standaard optie bij windows storage server 2003), maar als ik elke keer m'n database's + exchange down moet brengen vind ik dat niet grappig.

[Grolsch]

heb vanmorgen een e-mail gestuurd naar string bean software (wintarget), ik zal hun antwoord eens afwachten.

Een andere optie is om eenmalig alle devices offline te halen, en dan ff goed te defraggen, maar heb eigenlijk geen flauw idee hoe lang het duurt om een schijf van 680GB de defraggen

[sanfranjake]

Welk type storage server heb je? Een appliance? Bij onze HP zat een mooie defragtool (alleen lijkt het erop dat die in de R2-variant ineens verdwenen is)

[Grolsch]

sanfranjake schreef op donderdag 04 januari 2007 @ 16:08:
Welk type storage server heb je? Een appliance? Bij onze HP zat een mooie defragtool (alleen lijkt het erop dat die in de R2-variant ineens verdwenen is)

het is een Fujitsu Siemens Fibrecat N40i

zie http://www.multitask-computing.co.uk/storage/n40i.pdf voor meer info

Ik zal ook fujitsu siemens eens bellen.

[maratropa]

Een "poor-mans" defrag is gewoon bestanden van een partitie afkopieeren en ze er dan weer op zetten. Moet je wel de ruimte hebben natuurlijk. Maar ik kan me voorstellen dat dat soms sneller gaat dan defraggen met een tool.

[Grolsch]

wat een reactie van fujitsu siemens, echt te treurig voor woorden

Naar aanleiding van ons gesprek heb ik getracht de oplossing te vinden.

Helaas is die er niet. Als u in uw server een raid-configuratie heeft, hoeft u ze niet te defragmenteren, aangezien hij fault-tolerant is, dus hij is stevig van zichzelf. Ook gaat het niet lukken, omdat de data op verschillende schijven is opgeslagen, waardoor hij als hij gaat defragmenteren, in de war raakt wat waar hoort.

[seq_uence]

Ze hebben het niet echt door bij F-Siemens dat is wel duidelijk......

Onze MSA1000 volumes ben ik momenteel ook aan het bekijken, de trialversie van diskeeper kan ze netjes defraggen, maar het gaat hier dan ook om een fiber SAN.

[Grolsch]

ik ben nu ook een trial versie van diskeeper aan het downloaden, kijken of dat beter werkt.

[sanfranjake]

Waarom doe je het dan niet met defrag.exe van Windows zelf? Die wordt immers ook door Executive software gemaakt

[Grolsch]

sanfranjake schreef op vrijdag 12 januari 2007 @ 16:10:
Waarom doe je het dan niet met defrag.exe van Windows zelf? Die wordt immers ook door Executive software gemaakt

omdat m'n iSCSI dan onderuit gaat zoals vermeld in de TopicStart:

de shit is alleen dat als ik deze schijf ga defragmenteren er een dusdanige load op het systeem komt, dat m'n iSCSI disks kuren gaan vertonen en de koppeling verbreken waardoor dus onder andere m'n exchange en SQL over de zeik gaan.

[seq_uence]

En al getest met Diskeeper ?

[Grolsch]

nope, had ik afgelopen weekend willen doen, zal nu wel dit weekend worden.

ik ben benieuwd

[Grolsch]

ik heb het programma toch gisteren al geinstalleerd.
Ik heb het hier dus over de versie diskeeper 2007 enterprise server.

installatie gaat in een poep en een scheet, en is zo gebeurt.
Ik het automatic defragmentation aangezet in een timewindow van 20:00 t/m 07:30.

Verder met de hand een manual defragmentation op gestart.

Het resultaat van de analyse was dit:

Job Report
Volume NASDATA (E:):

Findings and Recommendations
--------------------------------------------------------------------------
Diskeeper has completed analysis of this volume and found
43,564 fragmented files and/or directories and 1,455,531
excess fragments.

The average number of fragments per file is 3.16.

Very heavy fragmentation detected on this volume. Turning
off Automatic Defragmentation for any parts of the day is
likely reducing performance.

Master File Table (MFT) usage is 80% or higher on this
volume. Use Frag Shield to configure the MFT on this volume
to better match the current MFT usage.


Health
--------------------------------------------------------------------------
Critical!

The overall health of volume E: is severely affected

The overall health is at "Critical" for the following
reasons:

1. The MFT usage is currently 84 percent of the total MFT
size, which indicates it is likely the MFT will become
fragmented.

2. The volume is heavily fragmented. The average number of
fragments per file is 3.16.


Access Time
--------------------------------------------------------------------------
Time to read fragmented files on volume E

Current read time: 3 hours

Optimum read time: 76 minutes

0% improvement


Time to read all files on volume E

Current read time: 5 hours

Optimum read time: 3 hours

0% improvement


Statistics
--------------------------------------------------------------------------

Volume Files
Volume size = 683 GB
Cluster size = 4 KB
Used space = 473 GB
Free space = 208 GB
Percent free space = 30 %

Fragmentation percentage
Volume fragmentation = 34 %
Data fragmentation = 48 %

Directory fragmentation
Total directories = 91,251
Fragmented directories = 1,931
Excess directory fragments = 6,040

File fragmentation
Total files = 668,116
Average file size = 824 KB
Total fragmented files = 41,632
Total excess fragments = 1,449,489
Average fragments per file = 3.16
Files with performance loss = 0

Paging file fragmentation
Paging/Swap file size = 0 bytes
Total fragments = 0

Master File Table (MFT) fragmentation
Total MFT size = 899 MB
MFT records In Use = 778,943
Percent MFT in use = 84 %
Total MFT fragments = 3

Ik heb de defragmentation gister avond opgestart rond een uur of 2100 en was zojuist op 38%
Ik laat hem lekker doorlopen omdat het de performance niet echt beinvloed zoals de standaard defragtool

Het resultaat zal ik hier vermelden.

[Grolsch]

en dit is het resultaat:

Job Report
Volume NASDATA (E:):

Findings and Recommendations
--------------------------------------------------------------------------
Diskeeper has completed analysis of this volume and found
304 fragmented files and/or directories and 354,476 excess
fragments.

The average number of fragments per file is 1.53.

Very heavy fragmentation detected on this volume. Turning
off Automatic Defragmentation for any parts of the day is
likely reducing performance.

Master File Table (MFT) usage is 80% or higher on this
volume. Use Frag Shield to configure the MFT on this volume
to better match the current MFT usage.


Health
--------------------------------------------------------------------------
Critical!

The overall health of volume E: is severely affected

The overall health is at "Critical" for the following
reasons:

1. The MFT usage is currently 84 percent of the total MFT
size, which indicates it is likely the MFT will become
fragmented.

2. The volume is heavily fragmented. The average number of
fragments per file is 1.53.


Access Time
--------------------------------------------------------------------------
Time to read fragmented files on volume E

Current read time: 88 minutes

Optimum read time: 61 minutes

0% improvement


Time to read all files on volume E

Current read time: 3 hours

Optimum read time: 3 hours

0% improvement


Statistics
--------------------------------------------------------------------------

Volume Files
Volume size = 683 GB
Cluster size = 4 KB
Used space = 482 GB
Free space = 200 GB
Percent free space = 29 %

Fragmentation percentage
Volume fragmentation = 27 %
Data fragmentation = 38 %

Directory fragmentation
Total directories = 91,277
Fragmented directories = 6
Excess directory fragments = 7

File fragmentation
Total files = 668,268
Average file size = 838 KB
Total fragmented files = 298
Total excess fragments = 354,469
Average fragments per file = 1.53
Files with performance loss = 0

Paging file fragmentation
Paging/Swap file size = 0 bytes
Total fragments = 0

Master File Table (MFT) fragmentation
Total MFT size = 899 MB
MFT records In Use = 779,197
Percent MFT in use = 84 %
Total MFT fragments = 1

Dus toch aanzienlijk beter als wat het was in ieder geval.

[alt-92]

Bij een zwaar gefragmenteerd volume kun je 'm het beste een paar maal achter elkaar laten draaien (elke dag) totdat het weer een beetje normaal is, en vervolgens een schedule instellen.