18
Backup Exec 2010 R3 Langsame Datenrate bei Backupjobs Disk to Tape
Hallo,
Wir haben neue Sicherungshardware beschafft, nur mit der neuen Hardware bekomme ich eine schlechtere Sicherungsperformance von Disk to Tape als auf den 6 Jahr alten Sicherungsserver mit LTO3 Loader.
Folgende Zusammenstellung haben wir jetzt in Betrieb:
Fujitsu Server 2 Intel Quad CPUs, RAM: 24 GB, 2 x Raid 1 146 SAS Harddisks, 2 NICS
Overland Autoloader Neo 200 LTO5 direkt über SAS am Fujitsu Server angeschlossen
Overland Snapserver SAN 2000 24TB, Raid 5, 1 GPT Disk mit 20 TB generiert, direkt Verbindung über ISCSI Kat 7 Kabel zum Backupserver. MPIO Aktiviert, Round Robin in ISCSI Initiator eingestellt.
Backup Software: Backup Exec 2010 R3 letzter Patchstand.
Meine Meinung dürfte der Flaschenhals beim Schreiben aufs Band irgendwo beim Lesezugriff von Backup Exec auf die SAN sein denn, was mich irritiert ist das ich mit den Analyse Tools von HP (HPcreateData und HPReadData) beim schreiben von kleinen und grossen Files eine Datendurchsatzrate von 120 bis 170 MB/sec bekomme.
Z.b. das Ergebnis von HPcreateData: Creating Data Set...
8354.50 MB written (7161 files) in 48 seconds, 174.05 MB/sec
Completed
Z.b. das Ergebnis mit grossen Files:
Creating Data Set...
21462.00 MB written (7154 files) in 129 seconds, 166.37 MB/sec
Completed
Ergebnis von HPReaddata: (Die geschriebenen Verzeichnisse werden jetzt von der SAN zum Backupserver gelesen.)
Scanning G:\TEMP\testmitkleinenFiles...
G:\TEMP\testmitkleinenFiles: 8354.50 MB read (7161 files) in 137 seconds, 60.98 MB/sec
TOTAL: 8354.50 MB read (7161 files) in 137 seconds, 60.98 MB/sec
Completed
Scanning G:\TEMP\testmitgrossenFiles...
G:\TEMP\testmitgrossenFiles: 21462.00 MB read (7154 files) in 68 seconds, 315.62 MB/sec
TOTAL: 21462.00 MB read (7154 files) in 69 seconds, 311.04 MB/sec
Completed
Also mit den HPAnalyse Tools bekomme ich sehr gute Werte. Auch die Netzwerkauslastung bei den beiden ISCSI Ports geht auf 99%. Die Bandbreite wird komplett ausgenutzt.
Wenn ich jetzt in Backup Exec einen Duplizierungsjob also von Disk to Tape starte, hat der Backupjob eine Auftragsrate von 800 MN /min (13MB/Sec) auf LTO5, was eindeutig fürs Streaming auf Tape zu wenig ist. Hier brauche ich mindestens 47MB/ sec damit der Schreib / Lese Kopt nicht in Stop and Go ist.
Die SAN ist defragmentiert und passt soweit. Ist es vielleicht möglich das Backup Exec eine Bandbreite definiert hat das pro Backupjob angewendet wird?.
Habe auch schon die Backup to Disk Ordner die ich zu einen Pool zusammen gefasst habe, neu angelegt -> gleiches Problem.
Vielleicht hat einer von euch eine Tipp für mich, ich suche nach der Lösung schon seit Wochen und spiele mich mit den Hobel rum ... ich finde es nicht.
Übrigens der Symantec Support hat mich nur auf das Performance Tuning Guide hingewiesen .. mehr hat er auch nicht gewusst... leider
Falls ihr irgendwelche Zusatzinformationen bräucht bitte posten.
Vielen Dank und lg
Lykantroph
Wir haben neue Sicherungshardware beschafft, nur mit der neuen Hardware bekomme ich eine schlechtere Sicherungsperformance von Disk to Tape als auf den 6 Jahr alten Sicherungsserver mit LTO3 Loader.
Folgende Zusammenstellung haben wir jetzt in Betrieb:
Fujitsu Server 2 Intel Quad CPUs, RAM: 24 GB, 2 x Raid 1 146 SAS Harddisks, 2 NICS
Overland Autoloader Neo 200 LTO5 direkt über SAS am Fujitsu Server angeschlossen
Overland Snapserver SAN 2000 24TB, Raid 5, 1 GPT Disk mit 20 TB generiert, direkt Verbindung über ISCSI Kat 7 Kabel zum Backupserver. MPIO Aktiviert, Round Robin in ISCSI Initiator eingestellt.
Backup Software: Backup Exec 2010 R3 letzter Patchstand.
Meine Meinung dürfte der Flaschenhals beim Schreiben aufs Band irgendwo beim Lesezugriff von Backup Exec auf die SAN sein denn, was mich irritiert ist das ich mit den Analyse Tools von HP (HPcreateData und HPReadData) beim schreiben von kleinen und grossen Files eine Datendurchsatzrate von 120 bis 170 MB/sec bekomme.
Z.b. das Ergebnis von HPcreateData: Creating Data Set...
8354.50 MB written (7161 files) in 48 seconds, 174.05 MB/sec
Completed
Z.b. das Ergebnis mit grossen Files:
Creating Data Set...
21462.00 MB written (7154 files) in 129 seconds, 166.37 MB/sec
Completed
Ergebnis von HPReaddata: (Die geschriebenen Verzeichnisse werden jetzt von der SAN zum Backupserver gelesen.)
Scanning G:\TEMP\testmitkleinenFiles...
G:\TEMP\testmitkleinenFiles: 8354.50 MB read (7161 files) in 137 seconds, 60.98 MB/sec
TOTAL: 8354.50 MB read (7161 files) in 137 seconds, 60.98 MB/sec
Completed
Scanning G:\TEMP\testmitgrossenFiles...
G:\TEMP\testmitgrossenFiles: 21462.00 MB read (7154 files) in 68 seconds, 315.62 MB/sec
TOTAL: 21462.00 MB read (7154 files) in 69 seconds, 311.04 MB/sec
Completed
Also mit den HPAnalyse Tools bekomme ich sehr gute Werte. Auch die Netzwerkauslastung bei den beiden ISCSI Ports geht auf 99%. Die Bandbreite wird komplett ausgenutzt.
Wenn ich jetzt in Backup Exec einen Duplizierungsjob also von Disk to Tape starte, hat der Backupjob eine Auftragsrate von 800 MN /min (13MB/Sec) auf LTO5, was eindeutig fürs Streaming auf Tape zu wenig ist. Hier brauche ich mindestens 47MB/ sec damit der Schreib / Lese Kopt nicht in Stop and Go ist.
Die SAN ist defragmentiert und passt soweit. Ist es vielleicht möglich das Backup Exec eine Bandbreite definiert hat das pro Backupjob angewendet wird?.
Habe auch schon die Backup to Disk Ordner die ich zu einen Pool zusammen gefasst habe, neu angelegt -> gleiches Problem.
Vielleicht hat einer von euch eine Tipp für mich, ich suche nach der Lösung schon seit Wochen und spiele mich mit den Hobel rum ... ich finde es nicht.
Übrigens der Symantec Support hat mich nur auf das Performance Tuning Guide hingewiesen .. mehr hat er auch nicht gewusst... leider
Falls ihr irgendwelche Zusatzinformationen bräucht bitte posten.
Vielen Dank und lg
Lykantroph
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 171174
Url: https://administrator.de/contentid/171174
Ausgedruckt am: 25.11.2024 um 23:11 Uhr
18 Kommentare
Neuester Kommentar
Hi Lykantroph,
hmmm, das ist wirklich lahm, meine Werte kennst du ja.
Wenn ich das richtige sehe, meinst du mit "2 x Raid 1 146 SAS Harddisks" wohl 2x 146GB, das ist leider nicht viel; sonst würde ich mal versuchen Daten von dort zum Tape zu schieben.
Wie schnell ist denn das Backup auf B2D, also der reine Backup-Job?
Von einer Bremse im Backup Exec ist mir nichts bekannt .... Moment mal, hast du eine extra iSCSI-Karte oder benutzt du die internen Netzwerkkarten mit dem Microsoft iSCSI-Provider?
Ich hatte mal einen Overland Neo2000 LTO3 per iSCSI angebunden, das war OK; hing aber auch an einer extra QLogic-Karte ....
VG
Deepsys
hmmm, das ist wirklich lahm, meine Werte kennst du ja.
Wenn ich das richtige sehe, meinst du mit "2 x Raid 1 146 SAS Harddisks" wohl 2x 146GB, das ist leider nicht viel; sonst würde ich mal versuchen Daten von dort zum Tape zu schieben.
Wie schnell ist denn das Backup auf B2D, also der reine Backup-Job?
Von einer Bremse im Backup Exec ist mir nichts bekannt .... Moment mal, hast du eine extra iSCSI-Karte oder benutzt du die internen Netzwerkkarten mit dem Microsoft iSCSI-Provider?
Ich hatte mal einen Overland Neo2000 LTO3 per iSCSI angebunden, das war OK; hing aber auch an einer extra QLogic-Karte ....
VG
Deepsys
Hi Deepsys,
Danke für deine Antwort. Genau 2 x 146GB SAS mit Raid 1. Wenn ich von Backupserver direkt ein grosses BKF File aufs Tape spiele dann bekomme ich zwischen 4000 und 5000 MB / min -> das sind auch Werte die spitze sind.
Ich habe eine fixe Onboard NIC Karte die für den Datenstrom verantworlich ist, eine zusätzliche NIC Karte hab ich dann für den Microsoft ISCSI Provider.
lg
Lykantroph
Danke für deine Antwort. Genau 2 x 146GB SAS mit Raid 1. Wenn ich von Backupserver direkt ein grosses BKF File aufs Tape spiele dann bekomme ich zwischen 4000 und 5000 MB / min -> das sind auch Werte die spitze sind.
Ich habe eine fixe Onboard NIC Karte die für den Datenstrom verantworlich ist, eine zusätzliche NIC Karte hab ich dann für den Microsoft ISCSI Provider.
lg
Lykantroph
Ich habe eine fixe Onboard NIC Karte die für den Datenstrom verantworlich ist, eine zusätzliche NIC Karte hab ich dann
für den Microsoft ISCSI Provider.
für den Microsoft ISCSI Provider.
Unser Reseller hat mir da zu einer QLogic QLE4060C geraten, das hat auch gut geklappt.
Allerdings keine Ahnung ob das nun wirklich soviel flotter ist, das hatte ich nie getestet.
Die Karte ist jetzt wieder an einem anderem Server, macht aber nur direktes Backup, also direkt aufs Band.
Das gibt dann 300MB/min (Differenziell, sehr viele kleine Dateien) und 1.300MB/min (Komplett Backup).
VG
Deepsys
Ich denke mal die Qlogic QLE4060C wird nicht viel andere Leistungsmerkmale haben als eine Intel 1GBit NIC.
Also ein paar Werte zu Backup to Disk Sicherungen und den dazugehörigen Duplizierungsjobs auf Band.
Exchange
B2D Exchange Sicherung (bestehend aus 14 Stores) 256 GB mit GRT habe ich einen Datendurchsatz von 1225 MB / min und dauert 5 Stunden.
Duplizierungsjob davon auf Tape hat eine Rate von 737 MB /min was echt zach ist.
backupjob mit vielen kleinen Files:
B2D: Zuwachssicherung von Files (21.037 Verzeichnisse und 1579 Files) 119MB /Min
Hier sehe ich es auch ein, bei einen Zuwachssicherungsjob bei sehr tief verzweigenten Ordnerstruktur braucht backup Exec sehr lang. Darum habe ich den Filserver backupjob in 10 Jobs gesplittet.
B2D SQL DB Job 300GB -> 3676 Mb/Min
Duplizierungsjob davon auf Tape: 3581Mb/min was auch ok ist. Bei SQL DB sind ja nur grosse Files.
Ich verstehe nicht das ich aber bei meiner alten Sicherungs Hardware bestehend aus einen Server mit 2 CPUS 2 Cores, 4GB RAM, 80GB Rai1, LTO 3 Overland Powerloader mit SATA to SCSI Anbindung und einer SATA to SCSI Applicane mit 4 TB bessere Ergebnisse bekomme als mit der neuen Hardware bekomme. Der neue Server fadisiert sich.
lg
Lykantroph
Also ein paar Werte zu Backup to Disk Sicherungen und den dazugehörigen Duplizierungsjobs auf Band.
Exchange
B2D Exchange Sicherung (bestehend aus 14 Stores) 256 GB mit GRT habe ich einen Datendurchsatz von 1225 MB / min und dauert 5 Stunden.
Duplizierungsjob davon auf Tape hat eine Rate von 737 MB /min was echt zach ist.
backupjob mit vielen kleinen Files:
B2D: Zuwachssicherung von Files (21.037 Verzeichnisse und 1579 Files) 119MB /Min
Hier sehe ich es auch ein, bei einen Zuwachssicherungsjob bei sehr tief verzweigenten Ordnerstruktur braucht backup Exec sehr lang. Darum habe ich den Filserver backupjob in 10 Jobs gesplittet.
B2D SQL DB Job 300GB -> 3676 Mb/Min
Duplizierungsjob davon auf Tape: 3581Mb/min was auch ok ist. Bei SQL DB sind ja nur grosse Files.
Ich verstehe nicht das ich aber bei meiner alten Sicherungs Hardware bestehend aus einen Server mit 2 CPUS 2 Cores, 4GB RAM, 80GB Rai1, LTO 3 Overland Powerloader mit SATA to SCSI Anbindung und einer SATA to SCSI Applicane mit 4 TB bessere Ergebnisse bekomme als mit der neuen Hardware bekomme. Der neue Server fadisiert sich.
lg
Lykantroph
Hi Deepsys,
Ich habe gerade eine interessante Erkenntnis erworben, heute habe ich mal eine Exchange Sicherung ohne GRT gemacht. Für die 260 GB Stores brauchte BE2010 auf Disk gerade mal 1 Stunde 40 also, finde ich mal ok soweit.
Danach startete ich eine Exchange SIcherung mit aktivierter Option GRT und siehe da ich bekomme eine Auftragsrate von 4500 MB / Min ...Wunderbar
)))
So jetzt meine Frage an dich, sicherst du deinen Exchange Store zuerst ohne und dann mit GRT? Können hier die vielen Exchange Logs die mitgesichert werden vielleicht die Performance bremsen?
lg
Lykantroph
Ich habe gerade eine interessante Erkenntnis erworben, heute habe ich mal eine Exchange Sicherung ohne GRT gemacht. Für die 260 GB Stores brauchte BE2010 auf Disk gerade mal 1 Stunde 40 also, finde ich mal ok soweit.
Danach startete ich eine Exchange SIcherung mit aktivierter Option GRT und siehe da ich bekomme eine Auftragsrate von 4500 MB / Min ...Wunderbar
)))So jetzt meine Frage an dich, sicherst du deinen Exchange Store zuerst ohne und dann mit GRT? Können hier die vielen Exchange Logs die mitgesichert werden vielleicht die Performance bremsen?
lg
Lykantroph
Vergiss es... i sehe den Wald vor lauter Bäume nimma...
lg
lg
Guten Morgen,
also ich sicher immer mit GRT
Leider fällt mir auch nichts mehr ein, außer mal ein Backup mit den lokalen Platten zu testen .....
Eine Idee hätte ich doch noch: Hast du die B2D-Verzeichnisse vom Virenscanner ausgenommen?
VG
Deepsys
PS: Du scheinst aber nicht aus NRW zu kommen, wir haben gestern um die Zeit unsere Server vor lauter Regen nicht mehr gesehen
also ich sicher immer mit GRT
Leider fällt mir auch nichts mehr ein, außer mal ein Backup mit den lokalen Platten zu testen .....
Eine Idee hätte ich doch noch: Hast du die B2D-Verzeichnisse vom Virenscanner ausgenommen?
VG
Deepsys
PS: Du scheinst aber nicht aus NRW zu kommen, wir haben gestern um die Zeit unsere Server vor lauter Regen nicht mehr gesehen
Guten Morgen Deepsys,
Auch auf den lokalen Festplatten hab ich es getestet -> selbe niedrige Auftragsrate.
Den Virenscanner habe komplett raus genommen.
Was mir aufgefallen ist, nach einer normalen Exchange Sicherung bekomme ich bei der GRT Sicherung doch eine bessere Auftragsrate -> 1500 MB / min.
Nur ich will Exchange nicht doppelt sichern.
Na wenn ich mal dahinter komme wo hier der Hund begraben ist dann poste ich es hier natürlich.
Regen? Wir hatten hier gestern 33 Grad, ich wohne in Wien.
lg
Lykantroph
Auch auf den lokalen Festplatten hab ich es getestet -> selbe niedrige Auftragsrate.
Den Virenscanner habe komplett raus genommen.
Was mir aufgefallen ist, nach einer normalen Exchange Sicherung bekomme ich bei der GRT Sicherung doch eine bessere Auftragsrate -> 1500 MB / min.
Nur ich will Exchange nicht doppelt sichern.
Na wenn ich mal dahinter komme wo hier der Hund begraben ist dann poste ich es hier natürlich.
Regen? Wir hatten hier gestern 33 Grad, ich wohne in Wien.
lg
Lykantroph
Was mir aufgefallen ist, nach einer normalen Exchange Sicherung bekomme ich bei der GRT Sicherung doch eine bessere Auftragsrate
-> 1500 MB / min.
Nur ich will Exchange nicht doppelt sichern.
-> 1500 MB / min.
Nur ich will Exchange nicht doppelt sichern.
Wo ist denn da der Sinn?
Du meinst doch das Backup vom Tape zu Band, warum sollte das schneller werden wenn du vorher eine "normale" Exchange-Sicherung gemacht hast?
Oder meinst du die Sicherung vom Exchange selber?
Regen? Wir hatten hier gestern 33 Grad, ich wohne in Wien.
Dann schöne Grüße nach Wien!
Hallo,
Leider habe ich noch immer das selbe Problem mit der Exchange DB GRT Sicherung. Ich bin jetzt mal von Backup to Disk Ordner weggegangen und Deduplziere es Medienserver seitig bei der Sicherung.
OK da die Sicherung schon zu letzt mit Backup to Disk 6 Stunde 16 Min benötigte spare ich jetzt mit der Dedup beim Sichern auf Disk 1 Stunde, jedoch beim Duplizieren aufs Tape benötigt der Job plötzlich 9 Stunden und fährt mit schneckenhafte 500MB / Minute.
Der Server fadisiert sich aber.
lg
Lykantroph
Leider habe ich noch immer das selbe Problem mit der Exchange DB GRT Sicherung. Ich bin jetzt mal von Backup to Disk Ordner weggegangen und Deduplziere es Medienserver seitig bei der Sicherung.
OK da die Sicherung schon zu letzt mit Backup to Disk 6 Stunde 16 Min benötigte spare ich jetzt mit der Dedup beim Sichern auf Disk 1 Stunde, jedoch beim Duplizieren aufs Tape benötigt der Job plötzlich 9 Stunden und fährt mit schneckenhafte 500MB / Minute.
Der Server fadisiert sich aber.
lg
Lykantroph
Hallo,
Hab jetzt mal 3 Hotfixes in Windows 2008 R2 eingespielt, alle 3 sollten die Disk Latenz, sowie I/O Diskperformance und den Storport Treiber fixen.
Dazu hab ich in der pd.conf (Konfig Datei des Dedub Ordners in Backup Exec) die Option Opt Dedub auf 1,5 GB / s feste Bandbreite gestellt.
Ist bei dir der Write Cache am Controller ausgeschalten ?
Genaueres sehe ich dann Moren wenn die Sicherungen gelaufen sind.
lg
Lykantroph
Hab jetzt mal 3 Hotfixes in Windows 2008 R2 eingespielt, alle 3 sollten die Disk Latenz, sowie I/O Diskperformance und den Storport Treiber fixen.
Dazu hab ich in der pd.conf (Konfig Datei des Dedub Ordners in Backup Exec) die Option Opt Dedub auf 1,5 GB / s feste Bandbreite gestellt.
Ist bei dir der Write Cache am Controller ausgeschalten ?
Genaueres sehe ich dann Moren wenn die Sicherungen gelaufen sind.
lg
Lykantroph
Also das einspielen von den 3 Hotfixes + BE2010 R3 SP1 + Hotfix hat schon zu einer gewissen Besserung beigetragen. Meiner Meinung geht aber 1. das Deduplizieren der Daten viel zu langsam und 2. das duplizieren auf Tape aus den Dedup folder gurkt mir 700 MB / Min auf LTO5 dahin.
Irgendeiner eine Idee ?
Irgendeiner eine Idee ?
Das Einspielen von BE 2010 R3 SP1 und den neuen Device Treiber brachte bei der Tapeduplizierung einen gewissen Vorteil in der Geschwindigkeit, dennoch besteht das alte Problem noch immer.
Symantec Advanced Team ist jetzt da dran, sollte sich irgendwas tun werde ich hier ein Update machen
Symantec Advanced Team ist jetzt da dran, sollte sich irgendwas tun werde ich hier ein Update machen
Symantec Advanced Team ist jetzt da dran, sollte sich irgendwas tun werde ich hier ein Update machen
Das Team ist mir ja mal komplett neu, was musstet du dafür nach Indien schicken?
Viele Glück und teile uns auf jeden Fall die Lösung mit!
VG
Deepsys
Servus Deepsys,
Der Support in Indien bei dem man zuerst hinkommt ist ziemlich furchtbar, den deutschen Support dort unten kannst sowieso vergessen. Ich hab einfach den Fall eskaliert und dann kommt der Case zum Advanced Team, das in Polen ist.
Danke ich hoffe ich bekommen das in Griff
lg
lykantroph
Der Support in Indien bei dem man zuerst hinkommt ist ziemlich furchtbar, den deutschen Support dort unten kannst sowieso vergessen. Ich hab einfach den Fall eskaliert und dann kommt der Case zum Advanced Team, das in Polen ist.
Danke ich hoffe ich bekommen das in Griff
lg
lykantroph
Hi,
Mittlerweile habe ich eine akzeptable Performancesteigerung erlangt, GRT Echange Sicherung läuft jetzt im Dedub Ordner auf 1500 - 2000 MB / min, das diskstaging von dedub auf Tape mit 1300 - 1500 MB/ MIn. Diese Auftragsrate habe ich erste mit den Einspielen von W2k8 R2 SP1 und ein paar Hotfixes bekommen.
Natürlich bin ich gewillt noch mehr Performance raus zubekommen, ein Symantec Techniker erzählte mir das ein Kunde die Exchange Sicherung mit über 5000 Mb / Min in GRT Modus macht, also da tät mir einer perönlich abgehen. Gut der sichert direkt auf Raid 1.
Welche Einstellungen habt ihr den in den Eigenschaften im Deduplication Ordner unter den Punkt Data stream chunk size ?. Standard ist ja 64kb.
Danke
lg
lykantroph
Mittlerweile habe ich eine akzeptable Performancesteigerung erlangt, GRT Echange Sicherung läuft jetzt im Dedub Ordner auf 1500 - 2000 MB / min, das diskstaging von dedub auf Tape mit 1300 - 1500 MB/ MIn. Diese Auftragsrate habe ich erste mit den Einspielen von W2k8 R2 SP1 und ein paar Hotfixes bekommen.
Natürlich bin ich gewillt noch mehr Performance raus zubekommen, ein Symantec Techniker erzählte mir das ein Kunde die Exchange Sicherung mit über 5000 Mb / Min in GRT Modus macht, also da tät mir einer perönlich abgehen
. Gut der sichert direkt auf Raid 1.Welche Einstellungen habt ihr den in den Eigenschaften im Deduplication Ordner unter den Punkt Data stream chunk size ?. Standard ist ja 64kb.
Danke
lg
lykantroph
hallo again...
Wollte mal wieder ein Update zu meine Problem liefern. Leider steckt die Firma Overland den Kopf in den Sand und tut so als würde das Performance Problem ihnen nichts angehen.
Hauptsache sie haben den Krempel verkauft und dahinter kann die Sinnflut kommen. Wir verwenden seit mehr als 10 Jahre Overland Storage Lösungen, diese wird wohl die letzte sein!!!!. NIE WIEDER !!!!
Aber genug Dampf abgelassen!
Ich habe heute bei den ISCSI NIC Settings die TCPOffloadEngine und die Option Large Send Offload deaktiviert, da gab es gleich mal bessere Werte, so ca. 1400 /Min bei einer Exchange GRT Dedup auf Tape Sicherung. Mit Zuschaltung der Flow Control Option bin ich schon auf 2100 MB/ min auf Tape))) und jetzt schalte ich noch die Jumbo Frames dazu -> 9014 kb und bin gespannt welchen Wert ich jetzt raus bekomme.
Meine Frage, hab ihr Flowcontrol und Jumbo Frames aktiviert ?.
Danke
lg
lykantroph
Wollte mal wieder ein Update zu meine Problem liefern. Leider steckt die Firma Overland den Kopf in den Sand und tut so als würde das Performance Problem ihnen nichts angehen.
Hauptsache sie haben den Krempel verkauft und dahinter kann die Sinnflut kommen. Wir verwenden seit mehr als 10 Jahre Overland Storage Lösungen, diese wird wohl die letzte sein!!!!. NIE WIEDER !!!!
Aber genug Dampf abgelassen!
Ich habe heute bei den ISCSI NIC Settings die TCPOffloadEngine und die Option Large Send Offload deaktiviert, da gab es gleich mal bessere Werte, so ca. 1400 /Min bei einer Exchange GRT Dedup auf Tape Sicherung. Mit Zuschaltung der Flow Control Option bin ich schon auf 2100 MB/ min auf Tape
))) und jetzt schalte ich noch die Jumbo Frames dazu -> 9014 kb und bin gespannt welchen Wert ich jetzt raus bekomme.Meine Frage, hab ihr Flowcontrol und Jumbo Frames aktiviert ?.
Danke
lg
lykantroph
Servus;
Wollte den Status noch bekannt geben. Das Problem ist mittlerweile behoben und man hat wieder ordentliche Auftragsraten in der Sicherung von Daten auf Disk und auch auf LTO5 Bänder.
Grund für diese Performance Problem war, dass der Snapserver S 2000 nicht für Backups geeignet ist. Auch wenn man mit diversen Diagnostic Tools ordentlich Auftragsraten von bis zu 70MB/s zusammen bekommt so hat man mit den Einsatz von Backup Exec ziemlich Probleme. Diese Probleme zeigen sich dann graviernd wenn man z.b. von Deduplizierungs Folder oder von einen normalen B2D Ordner mittels Duplizierungsjob die gesicherten Daten auf ein LTO5 Tape schreiben möchte. Hier kommt es dann zum Flaschenhals laut Overland ist die Ursache die Software in der S2000 die diesen verursacht.
Wir haben jetzt eine Reo4600, also eine VTL und hier sind die Backup Geschwindigkeiten nicht mit den alten zu vergleichen....
lg
lyantroph
Wollte den Status noch bekannt geben. Das Problem ist mittlerweile behoben und man hat wieder ordentliche Auftragsraten in der Sicherung von Daten auf Disk und auch auf LTO5 Bänder.
Grund für diese Performance Problem war, dass der Snapserver S 2000 nicht für Backups geeignet ist. Auch wenn man mit diversen Diagnostic Tools ordentlich Auftragsraten von bis zu 70MB/s zusammen bekommt so hat man mit den Einsatz von Backup Exec ziemlich Probleme. Diese Probleme zeigen sich dann graviernd wenn man z.b. von Deduplizierungs Folder oder von einen normalen B2D Ordner mittels Duplizierungsjob die gesicherten Daten auf ein LTO5 Tape schreiben möchte. Hier kommt es dann zum Flaschenhals laut Overland ist die Ursache die Software in der S2000 die diesen verursacht.
Wir haben jetzt eine Reo4600, also eine VTL und hier sind die Backup Geschwindigkeiten nicht mit den alten zu vergleichen....
lg
lyantroph
