Riverbed gebruikt ssd's in nieuwe wan-accelerators

Riverbed heeft ten behoeve van het reduceren van het verkeer tussen datacentra twee nieuwe wan-accelerators met een snelheid van 1Gbps uitgebracht. Het is voor het eerst dat het bedrijf solid state disks in dit type netwerkapparatuur toepast.

De Steelhead 7050-L en 7050-M zijn bedoeld om met behulp van technieken als caching en compressie het dataverkeer tussen datacenters te optimaliseren. Zo kan op de benodigde bandbreedte worden bespaard, terwijl toch dezelfde hoeveelheid data wordt overgebracht. De twee nieuwe machines verminderen de bandbreedtebehoefte met een factor drie tot acht, zegt Nik Roudam, die bij Riverbed verantwoordelijk is voor productmarketing.

De 7050-L en 7050-M kunnen volgens Roudam worden voorzien van respectievelijk 14 of 28 160GB-ssd's. Bovendien zijn er twee hdd's aanwezig die het loggen voor hun rekening nemen. De ssd's zijn tegen uitval beschermd dankzij een redundantiesysteem dat aan raid verwant is.

Onderling kunnen de apparaten via 10Gbps-ethernetverbindingen gekoppeld worden. Hierdoor kunnen ze als cluster worden ingezet, waarbij er een aantal Steelheads redundant kan worden geconfigureerd om problemen op te vangen. Een cluster van 25 Steelheads 7050's kan tot 12GBps aan data verwerken. De M-variant kan tot 75.000 connecties aan en de L-variant doet daar nog een schepje bovenop met maximaal 100.000 connecties. De 7050-L en de 7050-M worden nog dit kwartaal beschikbaar en zullen respectievelijk 180.000 en 235.000 dollar kosten.

Door Erik Kloppenburg

Nieuwsposter

10-02-2010 • 09:19

34

Reacties (34)

34
34
27
7
1
0
Wijzig sortering
Anoniem: 344712 10 februari 2010 11:39
Er wordt natuurlijk gekeken naar de Bandbreedte en wat deze kost over het optimaliseren van Apps zoals Citrix wat in de huidige versie van de Riverbed volledig wordt ondersteund en geoptimaliseerd.
Tevens staan deze units als TCP proxies in het netwerk wat er voor zorgt dat het eea lokaal kan worden afgehandeld (Pre-acks) en dat men het aantal roundtrips over het WAN verminderd wat er voor zorgt dat bijv een inefficient protocol als CIFS toch efficient kan werken over een WAN verbinding.
Er zijn nog veel dingen die je kunt doen om verkeer verder te optimaliseren, zoals gebruik maken van verschillende TCP vormen (ie TCP-Vegas) en het prepopulaten van de Riverbeds met data voordat de de gebruiker het opvraagt.
Het belangrijkste is voor deze 7050 oplossing is bijv bedrijven welke DWDM of gewoon gige hebben liggen tussen datacenters en hier bijv datareplicatie of backups over draaien.
Hiermee kunnen de tijden van de backups aanzienlijk worden verminderd, wat is het een bedrijf waard die in zulke omstandigheden werkt wel of geen data te verliezen.
Of hoe snel mijn DR omgeving up and running kan zijn met de laatste data set.

En ja de linken naar het buitenland zijn schreeuwend duur..

Just my 2 cents.

Wanop
Ik heb niet alle teksten gelezen dus wellicht dat iemand anders dit al heeft geschreven:
Riverbed heeft een hele speciale manier van caching en compressie die uniek is.
Er is een hele hechte samenwerking met allerlei fabrikanten als Microsoft, IBM, Oracle, etc zodat ze precies weten welk verkeer een applicatie genereert. Deze kennis wordt ingezet bij het versnellen van de data verkeer tussen locaties; of dat nu een ander datacenter is, een SOHO of de software matige Stealhead op een laptop in/op een Hotel/Vliegveld.. Met andere woorden, de portfolio van Riverbed is geheel schaalbaar dus: van een laptop/SOHO/Remote Office naar groter.
Een andere zeer interessante feature is de mogelijkheid om op een Stealhead appliance de Vmware “runtime” te bestellen. Betekent dus dat Vmware machines op de Stealhead appliance kunnen draaien. Denk aan bv een read-only DC, een printserver, etc. Aantal virtuele machines is afhankelijk van model en de type Vmware machine. Dat lijk t me logisch.
De aanschaf is een investering die zich snel terug verdiend doordat je minder frequent additionele bandbreedte hoeft aan te schaffen en bij gebruik van de Vmware “runtime” ook nog eens minder hardware hoeft te hebben op (kleinere-) locaties.
De dozen zijn plug&play, mits je netwerk goed is ontworpen. Daar zit de meeste tijd in bij de implementatie.
Kijk voor meer informatie op de website van Riverbed. PM’s zijn ook ok.
Guido
Kan iemand mij als netwerk-leek uitleggen wat deze dingen doen? Ik begrijp dat ze de efficientie verhogen van het dataverkeer tussen twee punten. Daaruit haal ik dat je aan beide zijden minimaal zo'n ding moet neerzetten. Ik begrijp alleen niet goed waar de winst in zit als dezelfde hoeveelheid data wordt verstuurd. Wordt dit gecomprimeerd? Wordt het uitgesmeerd over een langere tijd, waardoor je een kleinere lijn kunt gebruiken? Dat wordt voor mij in ieder geval uit het artikel niet duidelijk.
Deze apparaten doen verschillende dingen;

1) ze 'cheaten' suboptimale protocollen zoals CIFS door naar zowel tegen een file server als de client die een windows share gebruikt te 'zeggen' dat de data over is, terwijl deze pas in de WAN accelerator gecached is. Op een later tijdstip word de data pas doorgezet over het WAN. De gebruikers experience word hierdoor sneller.

2) de compressen het verkeer (eigenlijk een streaming variant van Winzip eroverheen)

3) een cache op block niveau/token niveau word er opgebouwd; Abstract voorbeeldje: stel je voor je opent een Word document van 100 paginas. Vervolgens bewerk je 1 pagina en save je het weer. Alleen die ene pagina word nu over het WAN verstuurd.
dat wordt niet alleen gecomprimeerd, maar ook gebufferd.

in de praktijk kun je je dat het beste voorstellen als het ophalen van 1 bestand vanaf de andere kant van de lijn. de eerste keer wordt dit in zijn geheel verzonden, en aan de ontvangerzijde gebufferd.

De tweede, derde en 123.456e keer dat hetzelfde bestand (hash oid) daarna nogmaals verzonden wordt doet het apparaat aan ontvangstzijde net alsof het bestand vanaf de andere kant van de lijn komt, terwijl er in feite maar een paar bits verzonden zijn en de bulk van de data uit de buffer van het apparaat opgediept is.
quote: artikel
De Steelhead 7050-L en 7050-M zijn bedoeld om met behulp van technieken als caching en compressie het dataverkeer tussen datacenters te optimaliseren
De eerste zin ;)
Anoniem: 341987 10 februari 2010 09:35
Wat is duur.....
Voor een verbinding naar bv Aruba is de bandbreedte niet het probleem (155Mb) maar de latency daar naar toe wel.
Voor het monitoren wat er allemaal over de lijn gaat zou ik geen riverbed gebruiken.
Ga er maar vanuit dat de latency niet veel beter wordt. Dit soort 'lapmiddelen' zijn een extra hop. Tuurlijk kun je compressie doen op die apparataten, maar dan is een applicatieve aanpassing of wellicht een VPN tunnel met compressie een stuk goedkoper en schaalbaarder (iedere CPU aan beide zijden van de lijn kunnen meewerken voor de compressie/decompressie).

Als je dit in wilt gaan zetten voor je failover dan heb je ook een probleem: als het ding cached in locatie A en het pas later naar B verstuurd heb je alsnog een Boeing probleem: land deze op A is je data in B toch outdated.

Lapmiddel dus en geen oplossing.
Latency heeft directe invloed op de throughput die je kan halen op een WAN lijn.
Hoewel je een Gigabit WAN lijn hebt liggen kun je er maar beperkt gebruik van maken.
( Bij TCP zit je te wachten op packets die aknowledged moeten worden. En dit scheelt bandbreedte. ) UDP heeft hier geen last van. Zeker als de latency wat hoger wordt, wordt de maximale throughput snel minder.

Dit speelt vooral bij backup en CIFS verkeer (Windows file sharing), wat een chatty protocol is.
Om één bestandje over te zenden worden er erg veel kleine IP packets verzonden. (Die ook allemaal aknowledge moeten worden.) Riverbed / Cisco WAAS is dus een TCP proxy.

Daarnaast cachen ze data op bit niveau. Wanneer een bestand gedownload is, staat dit in de cache van de stealheads. Wanneer je bijvoorbeeld in een Word bestand alleen een naam wijzigt, wordt alleen deze wijziging over de WAN link gestuurd.

Ze comprimeren data wat verstuurd wordt ook.

Door deze technieken worden applicatie over het WAN meer vloeien en voelen sneller aan. Backup windows van 24 uur kan je met WAN optimalisatie reduceren tot bijvoorbeeld 6 uur of minder. Data Center replicatie / backup is waar deze Steelhead 7000 series voor gebruikt worden. De geoptimaliseerde WAN throughput is dus 1 Gbps, maar aan de LAN kant kan dit 4 Gbps bedragen. Maar je kan ze dus ook clusteren.

Het ligt aan het type verkeer overigens hoeveel performance winst je kan halen.
Bij Backup, filesharing kan je aardige winst halen. Citrix / RDP verkeer is meer interactief verkeer en kan maar beperkt geoptimaliseerd worden. (Alleen het TCP proxy verhaal speelt hier eigenlijk.) Met encrypted wordt niets gedaan, want dit is random data.

Hier is een technische whitepaper te vinden over welke technieken men gebruikt om bandbreedte te beperken. De achterliggende technieken komen voor Cisco WAAS en Riverbed ongeveer overeen, maar Riverbed is in technische zin verder dan Cisco.

De latency blijft dus bestaan, maar de effecten van latency op netwerk protocollen kan je dus wel ondervangen.

Zie ook:
Cisco WAAS Mobile demo
Riverbed Stealhead demo

[Reactie gewijzigd door Bl@ckbird op 23 juli 2024 16:14]

Is het wel zo effectief om in plaats van een bak bandbreedte zo'n oplossing neer te zetten?
Ze zijn namelijk redelijk prijzig. Voor 25 van die dingen kan je ook voor 4 en half miljoen aan dataverkeer kopen. Natuurlijk zal het op de lange termijn goedkoper zijn maar toch... Datacenters die aan hun limietje zitten qua bekabeling hebben hier dan wel weer veel aan, omdat ze dan meer data kunnen versturen naar elkaar...

Samengevat is deze hele oplossing: DUUR Spotgoedkoop ;)

[Reactie gewijzigd door Grootstyr op 23 juli 2024 16:14]

Duur maar erg handig als je ze goed instelt kun je bijvoorbeeld een XML data stream tussen twee datacenters door middel van compressie een heleboel kleiner maken. Op die manier kun je flink wat kosten uit sparen. In landen als Nederland en België is het allemaal niet zo interessant bandbreedte kost geen drol een een flinke kabel kan je overal wel naar toe leggen. Maar er zijn ook andere landen op deze wereld...

Ik ben op dit moment bezig met het voor bereiden van een netwerk optimalisatie voor 200 landen. Alle landen moeten gebruik maken van 1 applicatie die op een centrale database staat. Maar veel landen hebben nu eenmaal niet een goede betrouwbare netwerk verbinding tussen het kantoor al daar en het datacenter. een 2Mbps lijn is vaak alles wat er beschikbaar is in landen als Ivoorkust, Cambodja en zo nog wat van die geweldige locaties. Als ik een beetje netwerk verkeer kan besparen in plaats van een nieuwe kabel te laten leggen over een afstand van enkele honderden kilometers berg, zee of woestijn dan is zo'n oplossing op eens wel heel erg aantrekkelijk.
Mijn grootste probleem... deze netwerk optimizers kunnen niet overweg met Citrix en dankzij de latency tussen de kantoren in het buitengebied en de rest van het netwerk (+600ms op de hop tussen het kantoor en de backbone is niet ongewoon) kunnen zij de applicatie die nog al zwaar op de database leunt niet lokaal draaien, naast de te verwachte problemen met het onderhoud van een applicatie op een paar duizend PC's over de gehele wereld.

Mijn huidige oplossing is niet Citrix maar de rest van het verkeer via een riverbed te laten verlopen, op die manier krijg ik de ruimte om het afgrijselijke Citrix protocol over die kleine kabeltjes te persen.
Ik weet dat deze nieuwe machines claimen met Citrix om te kunnen gaan maar eerlijk gezegd ben ik nog niemand tegen gekomen die daar in gelooft. Omdat we al redelijk war van die dingen hebben staan (oudere modellen die dus niet met Citrix overweg kunnen) zal ik voorlopig maar moeten aannemen dat ook deze nieuwe modellen niet echt veel hulp gaan bieden.

Ik denk dat het grootste probleem van het artiekel hier boven is dat het over verbindingen tussen datacenters spreekt waar in werkelijkheid dit soort dingen eerder ingezet worden voor het oprekken van verbindingen naar onmogelijke locaties.
Als je support contracten hebt op de Riverbed Steelhead applainces dan kan je de nieuwste versie van RiOS downloaden (versie 6.0)

Deze versie heeft verbeterde ondersteuning voor Citrix / RDP.
Zorg wel dat encryptie van de Citrix sessie op low of uit staat.
( Met radom data kan Riverbed niets doen. )
Misschien wil je eens kijken naar een webapp / web frontend voor die database ipv een volledige desktop via citrix.
Voor 200 landen moet er toch geld zijn om een web-app te laten bouwen.

Maargoed, het is pas een maandje 2010 natuurlijk.
Hehehe, ik zou niets liever willen maar in een bedrijf van dit formaat is dat minimaal net zo politiek ingewikkeld als een gemiddelde abortus wet door een willekeurig land aangenomen te krijgen. 8)7

Het probleem is de applicatie is geschreven in Uniface en wordt onderhouden door een erg moeilijk te sluiten afdeling in Spanje. Uniface is een absolute peop taal in dat bijvoorbeeld pas in versie 6 van de taal lokale variabelen mogelijk werden en dus ook het mee geven van parameters aan functie aanroepen.
Daar boven op komt dat de mensen in Spanje totaal geen behoefte hebben aan het veranderen van hun positie, als het een webbased applicatie wordt (wat al lang gebeurd had moeten zijn) dan zijn zij hun job security kwijt en dus doen zij er alles aan om aan te tonen dat het niet mogelijk is om dit tot een webapplicatie om te vormen. En als het dan echt moet dat weet ik zeker dat ze dit zullen doen met de laatste versie van Uniface die een soort van web forums kan maken.

Ik kan wel heel erg hard gaan schreeuwen maar het probleem is dat de developers al letterlijk een jaar of 10 a 15 aan deze applicatie werken en wie weet het nu beter. Dus ik concentreer me op een een van de andere tientallen applicaties waar ik ook bij betrokken ben daar waar wel een mogelijkheid is om dingen te verbeteren voor mijn dood. In een bedrijf met enkele honderdduizenden medewerkers wereldwijd is er altijd nog een heleboel te doen wat betreft IT. De lijst met applicaties die ik graag zou aanpassen is lang, heel erg lang en dit specifieke monster staat redelijk onder aan op die lijst.
Enig idee wat bandbreedte in die omvang kost? Daarbij vergeleken zijn deze dingen spotgoedkoop.

Plus dat je op deze manier wat meer controle hebt over wat er allemaal over de lijn gaat, en het het monitoren ervan behoorlijk vergemakkelijkt.
Interessante vraag! Aan 1 zo'n apparaat heb je uiteraard niets - je moet er 2 hebben: samen bijna 400k $. Daarmee verminder je de benodigde bandbreedte dan met een factor 3 tot 8. In plaats van een 1 Gbps link zou je dan dus toe kunnen met een 125 - 300 Mbps link. Ik kan me niet voorstellen dat dat prijsverschil een investering van 4 ton verantwoordt.

Wat wel een aspect zou kunnen zijn is het verminderen van de latency: applicaties zullen responsiever aanvoelen, en dat kan voor veel applicaties een groot pluspunt zijn.
Van 1Gbps naar 300Mbps misschien niet, maar van 20Gbps naar 12 o.i.d. scheelt flink in de kosten.

Zowiesow is het niet een investering die je een maandje gaat gebruiken heh.
4 ton investeren kan prima als je er +- 5 jaar mee vooruit kan, who cares?
Mits het een redelijk tot groot bedrijf is natuurlijk.
5jaar met ssd schijven in een server opstelling??? denk het eigenlijk niet
vergeet niet dat enkel schrijfacties de SSD doen verouderen (nou ja, voornamelijk schrijfacties)... Dus voor het beter leeswerk is een SSD uitstekend geschikt. Zeker als het
Ik denk dat je het vooral andersom moet zien. Door de besparing in bandbreedte hoef je bij groei in de nabije toekomst niet in extra bandbreedte te investeren. Ik denk dat de investering in dit soort apparaten dan opeens een stuk logischer is.
Bandbreedte is toch niet zo heel duur?
Maar als bandbreedte werkelijk zo duur is dan lijkt het me een mooie oplossing als bedrijf zijnde. Ik dacht altijd dat het juist de bandbreedte was die spot goedkoop was.

Het monitoren had ik nog niet eens aan gedacht...
Hangt ervanaf wat je met bandbreedte bedoelt. Kijk, een verbinding die je thuis hebt liggen van 20 mbit/sec ofzo is idd niet zo gek duur.

Maar we hebben het hier over het algemeen over een lijn met een tig grotere bandbreedte dan wat de gemiddelde consument heeft liggen. Een datacenter verbruikt over het algemeen namelijk iets meer capaciteit dan jan-met-de-pet die af en toe wat mailtjes stuurt zeg maar ;)

Een consumentenlijn is meestal nog eens shared ook (waardoor de kostprijs over meerdere mensen word uitgesmeerd), terwijl een lijn voor een datacenter over het algemeen dedicated is.

En veel datacenters zullen meer dan één lijn hebben ivm loadbalancing, redudancy en fault-tolerance etc.

[Reactie gewijzigd door wildhagen op 23 juli 2024 16:14]

Idd... we hebben het hier over lijnen die het mogelijk maken om een paar honderd al dan niet duizend klanten te voorzien van 100Mbit of 1000Mbit uplinks. :P
Leuk ding voor in mijn game pc :)
ik denk niet dat je helemaal begrijpt waar dit apparaat voor is?
..... met een factor drie tot acht,....


Jammer dat de hardware zo prijzig is. Dit zou voor kleinere bedrijven die één of meerdere 100Mbit lijnen hebben ook een uitkomst kunnen zijn.

Iemand een idee waarom er zo verschirikkelijk veel ssd's in moeten/kunnen?
Waarschijnlijk omdat het om verschrikkelijk veel data gaat (caching).
Anoniem: 332838 @GroGG10 februari 2010 09:49
Dit zijn ook zeker niet de instapmodellen. Wij hebben de SH1050 in gebruik voor het optimaliseren van onze 2 Mbit/s verbinding met ons hoofdkantoor in Duitsland. Onze bandbreedte wordt door de Riverbed met gemiddeld 70 % gereduceerd! De kosten van bandbreedte uitbreinding hebben wij al lang terugverdiend. Je wilt namelijk niet weten wat een internationale verbinding kost.... :-(
Zouden dit soort dingen ook ten kosten gaan van de latency van de verbinding?
Hoe zit dit bijvoorbeeld met Citrix omgeving of zou dit helemaal niets uitmaken?
kan me voorstellen dat dit bijvoorbeeld niet werkt met Citrix omdat je dikke vertraging krijgt op je lijn.

heeft iemand hier ervaring mee ?
Bij ons draaien ook Riverbeds (geen idee wel type, ik beheer ze zelf niet) tussen onze twee datacentra.

Wij hebben 160 Citrix-servers versreid over beide lokaties en dat werkt gewoon prima hoor. Ik ben de beheerder van de Citrix-infrastructuur, en merk weinig tot niets van latencies op dit gebied tussen de diverse Citrix-servers.

Vergeet niet dat het ICA-protocol waar Citrix mee werkt behoorlijk efficient is. Het is zelfs prima mogelijk om met ISDN een Citrix-sessie te draaien bijvoorbeeld.
hmm... cache en SSD's
ik denk niet dat die lang mee zullen gaan.
Als je maar zo'n 100.000 keer kan schrijven ben je ook snel klaar met het verkeer dat daar door heen moet gaan.
Dat valt wel mee denk ik.

Die 100.000 schrijfbewerkingen zijn per cel, niet voor de hele SSD. Tegenwoordig gebruiken SSD's allerlei slimme technieken om ervoor te zorgen dat niet steeds dezelfde cellen worden beschreven, om de slijtage zo minimaal mogelijk te houden. Deze techniek heet wear levelling.

Daarom zal het in de praktijk niet zo'n vaart lopen, zeker niet omdat in dit geval de bewerkingen ook nog eens over 14 of 28 SSD's worden verspreid. Waarschijnlijk is het apparaat eerder afgeschreven dan dat één van de SSD's het begeeft.
Daarnaast denk ik dat in een enterprise omgeving het preventief vervangen van SSDs niet echt een issue is als je kijkt naar de totale kosten. Preventief onderhoud lijkt mij aanzienlijk goedkoper dan een storing.

Op dit item kan niet meer gereageerd worden.