NIC teaming tussen Synology NAS en Windows server 2012

[bucovaina89]

Ik zou de snelheid van de link tussen onze backup server en Synology NAS willen (~)verdubbelen door een extra ethernetkabel tussen beide te trekken en beide NICs te laten samen werken zodat als de backup server een ~1TB file op de NAS op tape (LTO-5 SAS tape library) wil trekken dat dat over een link van in totaal 2Gb gaat.

De backup server draait Windows 2012 R2 (Standard denk ik) met Veeam Backup & Replication. Onze Synology is een up-to-date RS2212RP+ met 2 NICs en presenteert een SMB share op het "mini netwerk" tussen de NAS en backup server (directe link zonder switch). De netwerklink tussen beide is nu 1 directe ethernetkabel. Ik zou graag een 2e ethernetkabel willen tussen beide hosts om de snelheid van nu ~45MB/s te willen verhogen. Ik wil meer snelheid omdat:

• LTO-5 moet theoretisch max 140MB/s aankunnen. Nu zit ik aan ~45MB/s effectieve snelheid. Volgens mij krijgt de tape drive maar nét voldoende data binnen om niet telkens stil te vallen
• Weet niet wanneer maar als we ooit naar LTO-7/8/.../... upgradeden (max ~300MB/s), gaan we er echt niet meer komen met 45MB/s
• Ik heb voorlopig geen problemen met de backup window (een heel weekend) maar als het sneller kan graag dan

Maar dus mijn vraag: welke link mode moet ik dan hebben om een transfer van grote files die "serieel" worden getransfereerd te versnellen? Bij Synology kan je kiezen tussen

• Adaptive load balancing
• 802.3ad
• Balance XOR
• Active/Stand-by

Ik ben verre van een netwerkspecialist maar ik vermoed dat ik met geen van alle vernoemde modes echt een snelheidswinst ga boeken omdat onze backup server grote (.vbk, .vrb, .vib) bestanden een per een opvraagt en dus ook sequentieel naar tape schrijft. Er zijn dus niet meerdere "concurrent connections/flows" zoals je dus wel zou hebben stel dat 2 gebruikers tegelijkertijd 2 bestanden van een file server halen.

Ik denk eerder een balance-rr mode (vanuit Linux-land) in te moeten stellen omdat die de netwerkpakketten round robin gaat verdelen tussen de NICs. balance-rr is niet beschikbaar in de GUI/web interface van Synology maar wel in /etc/sysconfig/network-scripts/ifcfg-bond0. Alleen heb ik geen idee hoe ik een balance-rr (pakketten round robin over NICs sturen, ietwat manke vergelijking maar een RAID0 of zoiets ) network bond in linux mooi kan laten babbelen met een Windows Server 2012 R2.

Denk ik in de juiste richting en zo ja, kan iemand me in de juiste richting duwen? Gewoon al hoe balance-rr in de Microsoft wereld heet en/of een kb artikel of zo

[Vorkie]

Maar 1 link is 1Gbit/s?

Dan zou je max 125 MB/s moeten halen en daar zit je bij lange niet aan. (100-110MB/s realistischer)

Eerst dus kijken waarom je maar 45MB/s haalt, mogelijk zijn je disks gewoon te traag.

[ Voor 6% gewijzigd door Vorkie op 15-09-2018 19:57 ]

[Will_M]

Het lijkt me niet dat het probleem wat je nú ervaart te wijten is aan je netwerk bekabeling maar dat je het eerder eens moet gaan zoeken in de aansluiting/aansturing/configuratie van je LTO5 Tapelibrary.

Ga met bijv. iPerf eerst maar eens kijken welke snelheden je daadwerkelijk kunt halen op je netwerk.

[DukeBox]

@Vorkie en @wimmel_1 Bij tape is het nodig dat deze in steam-mode komt, wanneer er niet genoeg data wordt aangeleverd dan zal deze in start-stop mode werken. 45MB/s is een aardige indicatie dat dat nu het geval is.

@bucovaina89 Doorvoersnelheid verhogen tussen je server en de Synology kan alleen met iSCSI, dat is het enige protocol dat via MPIO daadwerkelijk de snelheid tussen P2P hoger kan krijgen dan een enkele verbinding. Via NFS en SMB kan het ook maar dat wordt op dit moment nog niet ondersteund op de NAS.

Indien iSCSI geen optie is kan je afhankelijk van je model NAS nog kijken of 10Gbit een optie is.

[ Voor 3% gewijzigd door DukeBox op 16-09-2018 12:52 ]

[Will_M]

@DukeBox Misschien dat dat Synology apparaatje ook wel (gewoon ) één Gbit NIC als dedicated BACK-UP NIC aan kan laten merken zodat je je back-up's over een eigen netwerk kunt trekken zonder dat je naar 10GBit NIC's hoeft uit te gaan wijken in de gehele keten.

Die 2012R2 Server heeft vast ook wel meerdere Gbit NIC's ter beschikking, hoop ik?

[Vorkie]

@DukeBox Ik ben mij bewust van de werking van de LTO streams, maar 45MB/s is erg laag en de grondslag kan dus net zo goed liggen in de Synology. (Gebruikte disken)

Verder kan hij beter kijken naar een DAS op de back-up server.

Veeam > DAS Back-upserver > Tape. (Eventueel een secondaire copy naar Synology voor QuickRestore (ipv vanaf tape trekken)

[DukeBox]

wimmel_1 schreef op zaterdag 15 september 2018 @ 20:12:
Misschien dat dat Synology apparaatje ook wel (gewoon ) één Gbit NIC als dedicated BACK-UP NIC aan kan laten merken zodat je je back-up's over een eigen netwerk kunt trekken...

Dan nog is dat niet genoeg om LTO5 in stream te krijgen.

Vorkie schreef op zaterdag 15 september 2018 @ 20:13:
Ik ben mij bewust van de werking van de LTO streams, maar 45MB/s is erg laag en de grondslag kan dus net zo goed liggen in de Synology. (Gebruikte disken)

Tuurlijk kan dat maar mag toch hopen dat TS dat al heeft uitgesloten. Hoe dan ook is 45MB/s een waarde die veel voorkomt bij bandbreedte problemen naar LTO5.

[Vorkie]

DukeBox schreef op zaterdag 15 september 2018 @ 20:21:
[...]

Dan nog is dat niet genoeg om LTO5 in stream te krijgen.


[...]

Tuurlijk kan dat maar mag toch hopen dat TS dat al heeft uitgesloten. Hoe dan ook is 45MB/s een waarde die veel voorkomt bij bandbreedte problemen naar LTO5.

Ik herken die 45MB/s ook bij Synology systemen (SATA schijven)

Dus ben benieuwd

[DukeBox]

Vorkie schreef op zaterdag 15 september 2018 @ 20:25:
Ik herken die 45MB/s ook bij Synology systemen (SATA schijven)

Heb alle synologys die ik heb/beheer met SATA maar snap niet precies wat je daar mee bedoeld.

[Will_M]

DukeBox schreef op zaterdag 15 september 2018 @ 20:21:
[...]

Dan nog is dat niet genoeg om LTO5 in stream te krijgen.


[...]

Tuurlijk kan dat maar mag toch hopen dat TS dat al heeft uitgesloten. Hoe dan ook is 45MB/s een waarde die veel voorkomt bij bandbreedte problemen naar LTO5.

Je gaat niet de maximale capaciteit en prestaties van een LTO5 tapedrive halen maar daar gaat 't nu ook niet om. Ook een LTO5 drive is terug te zetten naar de "streaming" capaciteit van een LTO3 drive (bijvoorbeeld). Voordeel van LTO5 is dan zuiver en alleen de grotere opslagcapaciteit per tape maar So Be IT!!

Hell: Al moet zo'n (dure!!) LTO5 drive op de snelheid van een DLT drive gaan streamen dan kán dat nog

[DukeBox]

wimmel_1 schreef op zaterdag 15 september 2018 @ 20:27:
Ook een LTO5 drive is terug te zetten naar de "streaming" capaciteit van een LTO3 drive (bijvoorbeeld).

Nee helaas, backwards compatibility is hoe dan ook maar tot 2 generaties read en 1 write.

https://docs.oracle.com/c..._Vol4_E4/LTO5_Vol4_E4.pdf
https://tapepower.fujifil...e/LTO6-TECHFLASH-2015.pdf

Streaming native data rate range
47–140 MB/s (LTO 5)

Ondanks dat ze het over range hebben, is alles onder de 140 niet streaming maar start stop. Soms haal je betere performance wanneer de data zo fluctueert dat nog net je buffer vol blijft. Maar met 1 Gbit/s is dat gewoon niet mogelijk en al helemaal niet wanneer je ook compressie gebruikt (en de data te comprimeren valt uiteraard).

[ Voor 5% gewijzigd door DukeBox op 15-09-2018 20:37 ]

[Question Mark]

Hoe heb je de snelheid nu gemeten? Oftewel, ga nu eerst eens na waar de bottleneck nu zit.

Als ik je goed begrijp wil je met VEAAM een backup maken vanaf je NAS, rechtstreeks naar tape? Ik hoop dat dat je de data snel genoeg en sustained kunt aanleveren om je LTO tapedevice in streaming mode te houden.

[DukeBox]

Question Mark schreef op zaterdag 15 september 2018 @ 20:35:
Ik hoop dat dat je de data snel genoeg en sustained kunt aanleveren om je LTO tapedevice in streaming mode te houden.

Dat is precies waar we het al de hele tijd over hebben..

@bucovaina89 Vergeet niet dat bij compressie van 2:1 je ook de dubbele data transfer nodig hebt. 2Gbit is dan zelfs te weinig.

[Will_M]

@DukeBox : I Stand corrected

Net even de HP Ultrium spec's er bij gepakt....

[bucovaina89]

DukeBox schreef op zaterdag 15 september 2018 @ 20:40:
[...]

@bucovaina89 Vergeet niet dat bij compressie van 2:1 je ook de dubbele data transfer nodig hebt. 2Gbit is dan zelfs te weinig.

Compressie in de LTO-drive staat voor zover ik weet niet aan. Dat lijkt me in ons geval weinig nuttig omdat ik veronderstel dat de backup files van veeam reeds gecomprimeerd zijn. Dat lijkt me wel een punt om na te kijken of dat effectief zo is.

Het lijkt me zoals je zegt de beste oplossing om voor iSCSI te gaan met 2 NICs.

Trouwens nog verder over stream mode en start/stop mode. Als je aan bijv. 100MB/s zit, past de drive zijn snelheid naar beneden aan. Volgens jou heet dat ook dan start-stop mode? Is dat in principe ook niet goed voor de drive/cartridge (buiten dan de lagere doorvoersnelheid) Ik ging er vanuit dat enkel als de drive begint te "shoe shinen" omdat de aanvoer te laag is, dat het pas echt slecht is en de performantie nog verder als een pudding totaal in elkaar zakt.

[DukeBox]

bucovaina89 schreef op zaterdag 15 september 2018 @ 20:49:
Dat lijkt me in ons geval weinig nuttig omdat ik veronderstel dat de backup files van veeam reeds gecomprimeerd zijn. Dat lijkt me wel een punt om na te kijken of dat effectief zo is.

De manier van hardware compressie is vrij effectief. Je zal geen 1:2 halen met veaam maar netto zal het zeker wel helpen. Daarmee helpt het ook met je recovery times en house keeping.

Als je aan bijv. 100MB/s zit, past de drive zijn snelheid naar beneden aan. Volgens jou heet dat ook dan start-stop mode? Is dat in principe ook niet goed voor de drive/cartridge (buiten dan de lagere doorvoersnelheid) Ik ging er vanuit dat enkel als de drive begint te "shoe shinen" omdat de aanvoer te laag is, dat het pas echt slecht is en de performantie nog verder als een pudding totaal in elkaar zakt.

Ja. Sterker nog, het is funest voor de levensduur van je drive en tapes. Waar LTO normaal gesproken (in een geconditioneerde ruimte) zeer weinig een clean nodig heeft zal het in dit geval regelmatig nodig zijn door al het slijtage stof.

Wij houden altijd minimaal 600MB/s aan PER drive, dat is ook de burst rate van de drive waarmee de buffer leeg kan lopen.

Vergeet niet dat voor restoren het zelfde geld.. je recovery time kan letterlijk weken i.p.v. uren zijn wanneer je veel (sequentieel beschikbare) data moet restoren.

Je kan evt. ook nog denken aan een virtual tape library op het systeem waar je drive aan hangt, die dient dan als grote buffer en i.c.m. veaam werkt dat in niet al te grote omgevingen out-of-the-box vrij goed.

Misschien nog een leuke toevoeging, week of 2 geleden bezig geweest met een 6 drive LTO6 library en flink wat storage.. Probleem was dat de backup (per dag een delta van max 34TB) niet meer lukte in het backup window van 8 uur. Sterker nog, vaak liep deze 12 tot 16 uur.

De bandbreedte was in dit geval niet genoeg om 6 drives in stream te krijgen (~2000MB/s) waardoor alles in elkaar zakte. Door 1 drive uit de backup pool te halen ging het wel goed waardoor de backup ruim binnen 6 uur klaar was.

[ Voor 29% gewijzigd door DukeBox op 15-09-2018 22:10 ]

[bucovaina89]

Thanks voor de tips. Actiepunten die ik van je mee neem:
* 140MB/s moet minimaal gehaald worden als doorvoersnelheid, bij voorkeur zelfs de max burst snelheid van de drive (600MB/s) al denk ik niet dat ik met onze synology daarmee ga geraken (zeker niet met 2NICs)
* VTL's onderzoeken wat we daar mee aankunnen, we hebben ook nog DAS op onze backup server wat we zouden kunnen toepassen als staging storage alvorens naar tape te trekken, maar geen idee hoe VTL's werken (ook maar net van je geleerd dat zoiets bestaat :-) ).
* Toch die compressie eens proberen. Ik ging er vanuit dat gecomprimeerde data nog verder proberen te comprimeren mogelijk zelfs averechts werkt. Mogelijk niet dan bij LTO. Te proberen waard mits ik de doorvoersnelheid voldoende hoog krijg.