Serverruimtes buitenshuis m.b.v. lage latency

[CORVETTE]

Wij zijn aan het orienteren om eventueel onze serverruimtes onder te brengen bij een externe partij.
En wij zijn ( meerdere ) fabrieken die een lage latency eisen vanwege aansturing in de fabriek.
Lage latency wil zeggen < 1 ms

Momenteel zijn wij verbonden met een soort van grote VPN tunnel. Dat is te langzaam, om onze servers daar ook onder te brengen.

We zitten nu te kijken naar zgn DarkFiber. Maar als we over latency beginnen bij externe partijen, willen die niets garanderen. Ja, geen uitval, maar daar kunnen we niet zoveel mee.

Stel dat wij 60km willen overbruggen naar onze serverruimtes, wat zou er dan voor latency kunnen zijn ?
Wat is het geval, als ze allerlei stukjes glasverbinding aan elkaar "knopen" ? Zou dat een hoge latency in de hand werken ?

Zijn er mensen die hier ervaring mee hebben, doordat hun servers ook buitenshuis staan, en over DarkFiber gaan ? Wat is jullie ervaring ?

[Andre_J]

Ik zelf werk ook in een fabriek, hier wordt ook de aansturing gedaan in de fabriek.
We hebben een gescheiden netwerk, 1 administratief netwerk ( office, erp, etc), het andere netwerk is puur voor de aansturingen in de fabriek.
Veel leveranciers van de sturingen leveren geen support als je bepaalde koppelingen maakt die de latency kunnen beïnvloeden. Daarom advies : server park intern houden!

[Perkouw]

Wat heb je zelf aan voor onderzoek gedaan en gevonden ? Voor dit soort vragen kan je imho beter een consultant inhuren. Hoe zit het bijvoorbeeld met het budget en al dat soort zaken? En is DarkFiber een specifiek product van een leverancier ? Zelf ken ik deze term alleen zoals hij hier wordt omschreven.

[ Voor 58% gewijzigd door Perkouw op 26-03-2013 19:59 ]

[Tjark]

Mijn vraag zou zijn: _als_ de verbinding naar buiten uitvalt, wat kost het (per uur) dat de fabriek dan stil ligt? (als die servers echt zo belangrijk zijn)

[Perkouw]

Tjark schreef op dinsdag 26 maart 2013 @ 19:59:
Mijn vraag zou zijn: _als_ de verbinding naar buiten uitvalt, wat kost het (per uur) dat de fabriek dan stil ligt? (als die servers echt zo belangrijk zijn)

Dat niet alleen, maar over wat voor soort data hebben we het en ga zo maar door.

[Stijnb_]

Bedoeld u met de sturing van de fabriek de automatisering van de machines en dergelijke?

[CORVETTE]

Als we DarkFiber zou willen nemen, dan willen we uiteraard 2 lijnen, mocht er eentje problemen geven, dan gaan we vrolijk verder over de andere.

[CORVETTE]

Stijnb_ schreef op dinsdag 26 maart 2013 @ 20:07:
Bedoeld u met de sturing van de fabriek de automatisering van de machines en dergelijke?

Niet direct de aansturing van de machines. Dat doen de PLC's maar, de PLC's worden weer aangestuurd door een soort van SAP. De PLC's blijven uiteraard in de fabriek, maar de aansturing naar de PLC's is heel belangrijk, door onze SAP.

[rdfeij]

1ms latency... dat bereik je volgens mij alleen door een decicated glasvezel te laten leggen.. (de meeste partijen zullen je een glasvezel aanbieden die verder over "internet" gerouteerd wordt en dan kunnen ze inderdaad niets garanderen) En dan nog zul je latency hebben omdat je wat switches/routers/firewalls toe moet voegen...

[Stijnb_]

CORVETTE schreef op dinsdag 26 maart 2013 @ 20:11:
[...]


Niet direct de aansturing van de machines. Dat doen de PLC's maar, de PLC's worden weer aangestuurd door een soort van SAP. De PLC's blijven uiteraard in de fabriek, maar de aansturing naar de PLC's is heel belangrijk, door onze SAP.

Ja, maar als je je SAP naar buiten plaats of via je server laat lopen die extern staan. Kunnen er soms wel problemen op treden.

[sypie]

Eigenlijk is het heel simpel: hoe meer onderdelen in de keten hoe groter de latency, hoe meer kans op storing en dergelijke.

Zet je het serverpark intern dan heb je een stuk minder onderdelen in de keten en kun je voor je eigen fabriek een kleinere latency afdwingen door fatsoenlijke apparatuur en kabels te gaan leggen. Hierbij heb je het grotendeels zelf in de hand.

Je kunt beter iedere fabriek redundant uitrusten om er voor te zorgen dat je machinepark lekker doorgaat terwijl jij een server aan het vervangen bent.

[webfreakz.nl]

Hoe meet je nu de latency?

[Andre_J]

sypie schreef op dinsdag 26 maart 2013 @ 20:19:
Je kunt beter iedere fabriek redundant uitrusten om er voor te zorgen dat je machinepark lekker doorgaat terwijl jij een server aan het vervangen bent.

Ben ik het volledig mee eens. Dat hebben wij dus ook, servers redundant, storage redundant.
Huurlijn, als die weg is, internet, dan isdn en in het uiterste geval schotel. Stilstaan kost 75k per uur dus ja dan moet je verbinding gegarandeerd zijn!

[spone]

Even denkend in de problematiek van de TS:

- Latency mag niet > 1 ms zijn
- SAP-achtige servers doen aansturing PLC's

Is het niet handiger om servers lokaal te hebben en een soort van replicatie-setup over een VPN naar een extern datacenter te hebben als failover? En eventueel dan de boel virtualiseren om replicatie als complete server te bewerkstelligen. Op die manier ligt de aansturing zo dicht mogelijk bij de fabriek zelf en ben je niet afhankelijk van externe factoren.

Ik werk bij een hostingpartij en wij hebben tussen kantoor en ons datacenter een directe fiber liggen. De afstand is hemelsbreed 800 meter. Latency is < 1 ms van client-to-server gezien en daar zitten nog enkele routers tussen.

Vanuit ons datacenter liggen er nog fibers naar 2 andere datacenters t.b.v. redundancy, elk iets van 20 kilometer weg en dat geeft geen noemenswaardige latency. Precieze latency weet ik zo even niet, maar ik geloof iets in de orde van minder dan 3 ms. Dit wordt geregeld door Eurofiber. Als je wil kan ik de precieze latency wel eens voor je nakijken/navragen.

[pablo_p]

Los van de discussie over wel of niet lokaal houden van servers (lijkt mij voor fabrieksaansturing wel wenselijk) wat over latency.

Ik werk in een omgeving waarin we een dual data center concept met stretched VLANs aan het opbouwen zijn en een van onze eisen was een redundante koppeling met latency onder de 1 ms. De afstand tussen de data centers is 20 km hemelsbreed. Intieel waren er twee paden van 0.72 en 1.1 ms latency RTT. Door een handiger tweede pad te laten kiezen was de latency RTT van het tweede pad 0.83 ms. De afstand glas is ongeveer 56 en 64 km respectievelijk (enkele weg). De betreffende data centers liggen bovenop glas-knooppunten (beter gesteld: zijn glas knooppunten).

Wat je hieruit kan leren:
- het valt nog best tegen om lage latency te hebben over twee redundante paden
- het vereist extra werk bij de glas provider om de beste paden uit te zoeken
- denk eerder aan een afstand van max 40 kilometer (en dat kan alleen als je hele gunstige aansluitingen hebt)

[RedShift]

Latency is altijd direct proportioneel tot de afstand. Even een simpele rekensom:

60 km / c = 0,2 ms.

Dus de minimum latency tussen de fabriek en het datacenter is sowieso 0,2 milliseconden, daar kan je niet onderuit.

Daarmee moet je ook nog rekening houden dat een pakketje niet direct aankomt, alle bits komen sequentieel toe. Laten we een gigabit interface nemen, deze kan 12 500 000 bytes per seconde verwerken. Laten we zeggen dat het gemiddelde ethernet frame 1 200 bytes groot is.

1 / (12 500 000 / 1200) * 1000 = 0.096 ms

Stel nu, dat er 8 routers moeten gepasseert worden. Dat wil zeggen, een interface ontvangt een frame, de router verwerkt hem en zet hem terug op de lijn.

Totaal per router: 0,096 ms + 0,096 ms = 0,192 ms
Langs 8 routers: 0,192 ms * 8 = 1,536 ms

Hierbij laat ik nog de volgende variabelen weg:

* De tijd nodig om het pakketje van de buffer van de interface naar de CPU of ASIC te krijgen
* De tijd nodig om de ASIC het pakketje te laten verwerken
* De tijd nodig om het pakketje van de ASIC naar de doelbuffer te krijgen

Dus, om een pakketje 60 km ver te sturen langs 8 routers, kom je uit op:

0,2 + 1,536 = 1,735 ms.

Round-trip levert dit 3,47 ms op (ping meet round-trip tijd)

En dat is dan nog onder ideale omstandigheden met allerlei factoren weggelaten:
* We vergeten bijvoorbeeld dat er tragere media tussen de fabriek en het datacenter zitten (tragere links = hogere serialization delay).
* We gaan er van uit dat er geen congestie is
* In de praktijk zal de afstand dat pakketjes afleggen tussen de fabriek en het datacenter altijd veel hoger zijn, vermits je ISP geen directe lijn van de fabriek naar het datacenter legt. Kan evengoed het driedubbele zijn!
* De computers aan beide kanten hebben ook verwerkingstijd nodig (CPU cyclussen), dat is hier ook weggelaten.
* Repeaters zijn ook weggelaten. Afhankelijk van het type zit hier ook serialization delay op.

Je spreekt ook van een eigen fiberverbinding te leggen, eerlijk gezegd denk ik dat dat nog altijd zeer moeilijk zal zijn om daar onder de 1 ms te blijven. Het snelste van het snelste (10 Gbit) zal helpen, maar zoals je zelf aanhaalt, niemand zal latency waardes van zo laag in zijn SLA opnemen, omdat het gewoon onmogelijk is om te garanderen.

Conclusie: het publiek internet zal je nooit de lage latency waardes kunnen geven dat je zoekt.

[DukeBox]

Ter info, wij gebruiken evpn van 100Mbit van KPN tussen 2 locaties die zo'n 11KM hemelsbreed van elkaar liggen.
Ben normaal gesproken geen fan van KPN maar de lijn heeft vrijwel geen latency (althans, linux ping geeft tussen 0.080 en 0.150 aan).
Naar een andere locatie welke 280KM verder ligt is de latency gemiddeld 4.241ms (10Mbit evpn).
Dit overigens voor een fractie van de kosten van een darkfiber.

[DJSmiley]

Darkfiber is een prijzige oplossing in de meeste gevallen, tenzij je echt on-net zit en je een leuke deal kunt maken. Maar in de praktijk is dat vrij zeldzaam.

Op zich kun je ook via een vlan of evpn-achtige oplossing prima lage latency's krijgen, maar dat is net afhankelijk van de setup van het netwerk. Als je samen op 1 switch zit is het verwaarloosbaar, als het echter een complete route af legt kan het compleet anders zijn.
Overigens kun je vaak ook wel garanties op verbindingen krijgen, alleen betaal je dan ook de jackpot. (normale verbindingen zijn meestal best-effort, maar je kan ook premium nemen)

Voor darkfibers kun je informeren bij de grotere partijen: Eurofiber, Relined oid. Als je binnen het dekkingsgebied van een lokale IX zit is dat misschien ook nog een optie om op die manier wat voordeliger een verbinding te krijgen.
Soms heb je ook lokale partijen met glas in de grond, mogelijk kunnen hun ook een darkfiber leveren. Ik heb bij een klant een verbinding draaien over 15km ofzo, voor <750 eur/mnd uit mn hoofd. Maar goed, dan ben je meestal wel beperkt tot de kortere afstanden. 60km kan prima, maar dan zit je toch meestal bij de grotere jongens.

Wat is het budget? Reken toch snel op 2-3k per maand, excl aanleg. (10-20k gok ik) en apparatuur (5-10k, beetje afhankelijk of je 1Gbit of 10Gbit wilt doen). Een 10Gbit 80km optic is alleen al 3k voor een OEM ding..

Je kan ook informeren voor een wave. Als je in een gebied zit met een redelijke infra is een wave misschien goedkoper dan een dedicated fiber.

Maar wie beheert je huidige infra? Laat hun eens een paar offertes maken. Hun zullen vaker dergelijke vragen gehad hebben gok ik. Of informeer eens bij je lokale IT tent, hun weten vermoedelijk wel wat er in de regio aangeboden wordt.

[ Voor 13% gewijzigd door DJSmiley op 26-03-2013 21:39 ]

[CORVETTE]

DJSmiley schreef op dinsdag 26 maart 2013 @ 21:33:

Maar wie beheert je huidige infra? Laat hun eens een paar offertes maken. Hun zullen vaker dergelijke vragen gehad hebben gok ik. Of informeer eens bij je lokale IT tent, hun weten vermoedelijk wel wat er in de regio aangeboden wordt.

Dat doe ik grotendeels, maar verder dat wat standaard switch / router werk kom ik niet.

Ik wilde eerst wat meer praktijk informatie voordat we het bij andere IT toko's navragen. Beetje eigen input is nooit weg.

[Bl@ckbird]

Laat ik voorop stellen dat ik weinig weet van SAP. Om lage latency te halen moet je servers altijd lokaal draaien. Ik weet niet in hoeverre je gedistribueerde SAP servers kan repliceren naar een centraal datacenter. Dit zou je eens moeten informeren.

Waar je ook naar kan kijken welke invloed hoge latency heeft op het SAP verkeer. Latency kan je niet je niet voorkomen, maar je kan de effecten van latency op dataverkeer wel oplossen, door bijvoorbeeld WAN optimalisatie. Hoge latency heeft bijvoorbeeld invloed op de max. throughput van CIFS verkeer. (Windows filesharing.) Hoge latency kan bijvoorbeeld er ook voor zorgen dan een ICA of RDP sessie stroperig aanvoelt. Dit komt hoe TCP (en bovenliggende applicatie lagen) werkt.

Zo zijn er WAN simulators waarmee je latency en bandbreedte kan simuleren. WAN optimalisatie fabrikanten als Cisco en Riverbed hebben demo programma's om dingen te testen. Je kan dat testen welke mate van latency, welke invloed heeft op SAP verkeer. (Met en zonder WAN optimalisatie.) Doe dit altijd samen met een SAP consultant.

Verder zijn er switches die erg lage latency hebben. (250 tot 190 nanosec.) Deze zijn speciaal bedoelt voor de financiële sector. (High frequency trading in aandelen en opties.) Maar dit zijn dure units.

[Exhar]

Ha, toevallig net bezig met het opleveren van een ulta-low latency verbinding. Van Duitsland naar Engeland. Minder dan 5ms latency RTD (precieze getallen mag ik niet noemen).

Truuk? Microwave verbindingen! Daar kan je eens naar kijken. Wat het qua kosten doet, geen idee, maar voor je latency is het goed! Oh, en alles moet op 64 byte zitten: grotere frames zijn 'killing' (al snel een 500/600 nano seconden extra). Zoals al geroepen zit je ook vast aan 10Gbit interfaces ivm. de serialization delay.

Bl@ckbird schreef op woensdag 27 maart 2013 @ 00:04:
[..]
Verder zijn er switches die erg lage latency hebben. (250 tot 190 nanosec.) Deze zijn speciaal bedoelt voor de financiële sector. (High frequency trading in aandelen en opties.) Maar dit zijn dure units.

En dan noem je hier nog een van de 'langzamere'. Kijk maar eens naar Gnodal of Zeptonics. Zijn beide nog stuk goedkoper ook. Maar zullen wel minder opties dan de Cisco's hebben ja.

[ Voor 8% gewijzigd door Exhar op 27-03-2013 00:16 ]

[jvanhambelgium]

Sowieso is de conclusie dat je een serieuze hoop geld op tafel mag gaan leggen eenmalig en maandelijk...kosten/baten analyse dan nog maar eens (laten) maken ?

DarkFiber kan bij ons ook, ontdubbelde paden ook, dan aan beide kanten een Cisco Nexus oid (lage latency) en daarin 10G singlemodes proppen en dan zit je nog wel ruim < 1ms indien de afstanden dit allemaal toelaten en dat zal de provider wel zien na een kleine studie.

[pablo_p]

@Redshift: de lichtsnelheid in glasfiber is effectief 200.000 km/s, niet 300.000. Dit wordt veroorzaakt door de brekingsindex van glas van 1.48.

Zie http://home.tiscali.nl/el...ument/Glasvezelkabels.pdf

[brederodekater]

Exhar schreef op woensdag 27 maart 2013 @ 00:13:
Ha, toevallig net bezig met het opleveren van een ulta-low latency verbinding. Van Duitsland naar Engeland. Minder dan 5ms latency RTD (precieze getallen mag ik niet noemen).

Truuk? Microwave verbindingen! Daar kan je eens naar kijken. Wat het qua kosten doet, geen idee, maar voor je latency is het goed! Oh, en alles moet op 64 byte zitten: grotere frames zijn 'killing' (al snel een 500/600 nano seconden extra). Zoals al geroepen zit je ook vast aan 10Gbit interfaces ivm. de serialization delay.
[...]

En dan noem je hier nog een van de 'langzamere'. Kijk maar eens naar Gnodal of Zeptonics. Zijn beide nog stuk goedkoper ook. Maar zullen wel minder opties dan de Cisco's hebben ja.

Ik kan me niet voorstellen dat de TS geintereseerd zal zijn in een microwave verbinding. Aangezien je zelf bezig bent met een oplevering, dan weet je vast ook hoe onbetrouwbaar deze verbindingen zijn

Oh ja, Zeptonics is zo goed als dood

[Exhar]

brederodekater schreef op woensdag 27 maart 2013 @ 14:18:
[...]


Ik kan me niet voorstellen dat de TS geintereseerd zal zijn in een microwave verbinding. Aangezien je zelf bezig bent met een oplevering, dan weet je vast ook hoe onbetrouwbaar deze verbindingen zijn

Oh ja, Zeptonics is zo goed als dood

Betrouwbaarheid van 99.95% is niet de beste ooit inderdaad, haha. Maar 't hangt van de omgeving af welke garanties gegeven kunnen worden.

Wat ik van Zeptonics begrijp, gaat 't niet om de Zeptomux, maar de andere producten... Ah well

[CORVETTE]

Zijn de ervaringen met zgn Microwave niet goed ?

[Freeaqingme]

Ik ben toch op zoek naar wat context. Stel dat er nog andere oplossingen zijn welke een stuk goedkoper en betrouwbaarder zijn, zou het zonde zijn die nu te missen.

Ben bijvoorbeeld wel benieuwd, dat als je je machines aanspreekt middels PLC's (wat een bijzonder logische keuze lijkt ), dan kunnen die plc's ook wel met 5 ms delay aangesproken worden?

[CORVETTE]

Daar heb je gelijk in. Maar 5 ms delay bij de plc's gaat echt niet werken. In die 5 ms hebben de plc's al wel 3x wat doorgeven. Je moet het zien als een grote lopende band waarom goederen liggen, die snel links of rechtsaf moeten. Wanneer daar vertraging of hiks in zitten, dan wordt het aan het eind van de band "gedumpt" en moet het er weer op ( lees: hoop werk ). En uiteraard is: hoe sneller alles werkt hoe meer op het op elkaar afgestemt is. En nu is het zo dat het vrij critisch is als daar vertragingen op zitten. Lees: ze zittten redelijk in de buurt van wat mogelijk is qua snelheid.

[DukeBox]

Microwave/radio verbindingen kunnen opzich net zo snel (in theorie soms zelfs sneller) werken echter zijn ze minder betrouwbaar en hebben meer last van externe invloeden (zoals weers omstandigheden, stoor signalen)

Freeaqingme schreef op woensdag 27 maart 2013 @ 19:27:
..Stel dat er nog andere oplossingen zijn welke een stuk goedkoper en betrouwbaarder zijn, zou het zonde zijn die nu te missen.

Als die er zou zijn.. dan zou iedereen wel gek zijn om je scheel te betalen aan dark fibers

[Paul]

Die PLC's maken beslissingen, ongeveer 600 per seconde, en dat heeft allemaal input uit andere systemen nodig? Voor iedere beslissing connect je met de server, deze vergelijkt *iets* met *iets*, roept een database aan (??) en stuurt het antwoord op de beslissing terug...

Kun je niet beter kijken waarom die PLC de beslissing niet zelf kan maken maar info nodig heeft van iets dat zich 60km verderop bevindt? Dan heb je die hele low-latency-verbinding niet meer nodig en kun je alles bij de machines houden die die info nodig hebben.

Tenzij dat nu al het geval is en je sec op zoek bent naar een manier om die PLC's (of de aansturing daarvan) 60 km verderop neer te zetten, en dan is de vraag: Waarom?

Housing van je MER / computerruimte te duur? Local IT nodig waar je die liever centraliseert? Iets anders?

Voor het geld dat je nodig gaat hebben om alles te verplaatsen kun je best een paar UPS'en, verhoogde vloeren, airco's, celbetonblokken en iLO/DRAC-licenties voor kopen Je productieproces is prio nummero uno, de ICT is daarbij facilitair. Dan is de marges opzoeken en veel geld uitgeven om de boel centraal neer te zetten terwijl de omgeving zich daar (deels) eigenlijk helemaal niet toe leent in mijn ogen niet de beste dienstverlening

Er is uiteraard niks mis met het zoeken van de technische oplossing van dit probleem maar houdt daarbij in de gaten of de kosten nog tegen de baten opwegen

[CORVETTE]

Centralisatie. Dat is de reden. Wij hebben meerdere zuster fabrieken.

Misschien dat een spreiding dan beter zou zijn: Database + erp bij fabriek zelf, ka met dikke lijnen centraal.

[Freeaqingme]

DukeBox schreef op woensdag 27 maart 2013 @ 20:16:
Microwave/radio verbindingen kunnen opzich net zo snel (in theorie soms zelfs sneller) werken echter zijn ze minder betrouwbaar en hebben meer last van externe invloeden (zoals weers omstandigheden, stoor signalen)

[...]

Als die er zou zijn.. dan zou iedereen wel gek zijn om je scheel te betalen aan dark fibers

Ik heb het meegemaakt hoor, dat leverancier A voor de in hun ogen 'beste' oplossing ging, en 250K / jaar offereerde, terwijl partij B een offerte had van <2.5k per maand. Partij A had aan de hand van dezelfde eisen een compleet andere oplossing bedacht, terwijl de klant met de goedkopere oplossing al haar wensen vervuld zag worden.

Tuurlijk, het kan zijn dat je een situatie hebt waarin Dark Fiber de beste oplossing is, maar zonder context is het jammer als we daar al van vooraf aan vanuit gaan. Zie ook de reactie van Paul, PLC's programmeer je zelf ook al natuurlijk (en hebben veelal ook eigen sensoren), dus die zijn vaak goeddeels atomair te gebruiken.

@Corvette, misschien kan je iets meer toelichten over waar die PLC's die servers voor nodig hebben, en wat 'ka' betekent?

[ Voor 5% gewijzigd door Freeaqingme op 27-03-2013 20:51 ]

[Paul]

Kantoorautomatisering centraal, helemaal mee eens, maar dat soort kritische zaken die verder niet of amper input nodig hebben van of verbonden zijn met de rest, tja...

Ik zou inderdaad kijken waar de lijn te trekken is tussen "Deze doos is puur en alleen maar voor machine X op locatie Y" en "Deze doos voert taken uit voor afdeling A, B en C" en de machines overeenkomstig neerzetten.

Wij doen iets soortgelijks, we hebben eilandjes met daaraan alle sensoren en monitoren etc. Die eilandjes hebben wel een centrale database, maar ze kunnen 96 uur autonoom draaien. In de centrale database staan de jobs opgeslagen / ingeschoten, maar de eilandjes beheren autonoom hun eigen gebied.

[brederodekater]

Exhar schreef op woensdag 27 maart 2013 @ 17:26:
[...]

Betrouwbaarheid van 99.95% is niet de beste ooit inderdaad, haha. Maar 't hangt van de omgeving af welke garanties gegeven kunnen worden.

Wat ik van Zeptonics begrijp, gaat 't niet om de Zeptomux, maar de andere producten... Ah well

Wij hebben een aantal van dit soort links & zodra er een stormpje/regen/mist de kop op steekt kun je er donder op zeggen dat ze eruit klappen.

Hopen dat je een goede SLA refund policy op die link hebt, dan heb je wel een goede deal met zo'n 99.95% uptime garantie

[jvanhambelgium]

CORVETTE schreef op woensdag 27 maart 2013 @ 20:12:
Daar heb je gelijk in. Maar 5 ms delay bij de plc's gaat echt niet werken. In die 5 ms hebben de plc's al wel 3x wat doorgeven. Je moet het zien als een grote lopende band waarom goederen liggen, die snel links of rechtsaf moeten. Wanneer daar vertraging of hiks in zitten, dan wordt het aan het eind van de band "gedumpt" en moet het er weer op ( lees: hoop werk ). En uiteraard is: hoe sneller alles werkt hoe meer op het op elkaar afgestemt is. En nu is het zo dat het vrij critisch is als daar vertragingen op zitten. Lees: ze zittten redelijk in de buurt van wat mogelijk is qua snelheid.

Het kan toch niet zijn dat de PLC's niet autonoom kunnen werken en constant aan servers allerlei dingen moeten vragen ? En dan nog wel over "ethernet" , de minst voorspelbare tov anderen zoals Profibus of RS485.
Die PLC's werken toch zelfstandige hun programma af met input van allerlei analoge/discrete inputs en sturen dan direct ook uitgangen aan ? (analoog/discreet)

Ik kan begrijpen dat de servers die jullie willen verplaatsen vb bepaalde SCADA systemen kunnen zijn, maar dat het zoooo tijdsgevoelig is...

[DukeBox]

Freeaqingme schreef op woensdag 27 maart 2013 @ 20:50:
Tuurlijk, het kan zijn dat je een situatie hebt waarin Dark Fiber de beste oplossing is, maar zonder context is het jammer als we daar al van vooraf aan vanuit gaan.

Oh, nee, zo bedoel ik het helemaal niet. Het enige dat ik er eigenlijk mee wilde zeggen is dat een darkfiber vrijwel geen nadelen kent (anders dan de prijs), daardoor is het een betrouwbare oplossing.
Dat neemt niet weg dat er andere betrouwbare oplossingen kunnen zijn die veel economischer zijn.

Ik heb zelf radio ingezet op een aantal lokaties (31MHz licentie, 2,4GHz, 5GHz, 60Ghz) over afstanden van een paar honderd tot zo'n 7KM. Met snelheden van 3x2Mbit tot 450Mbit. Maar zonder (zoals eerder aangegeven) je hele netwerk erop in te stellen heb ik er nooit latency's uit gehaald die lager waren dan darkfibers van gelijke lengte. Ik vraag me dus heel erg af of het haalbaar is.

[Predator]

Ik heb hier 2 datacenters met 2x een layer-2 gig link.
Dat is geen darkfiber (moeilijk te krijgen in België), bijna geen enkele operator wil dat nog doen voor nieuwe klanten. Enkel Eurofiber doet het nog. Andere bieden alleen managed aan.

We hebben lan extension links die wel L2 zijn, geen L2overL3, en de latency is laag.
Ik heb geen echte meting daarvan, maar een unix-ping naar een server in het andere DC komt wel al onder de 1ms uit, dus de echte latency is een stuk lager. (Afstand is 10km)
Je verliest vooral veel als er router hops tussen zitten.

Maar garanties krijgen van een leverancier gaat moeilijk blijven. Het lijkt me riskant om de sturings servers op locatie weg te halen.

[Uberprutser]

Predator schreef op donderdag 28 maart 2013 @ 10:38:
Maar garanties krijgen van een leverancier gaat moeilijk blijven. Het lijkt me riskant om de sturings servers op locatie weg te halen.

Mijn advies zou daarom ook zijn: doe het niet.

de lage latency die je nodig hebt en het gebrek aan dark fiber moet je wel een hele knappe provider hebben die dat redelijk betaalbaar aan kan bieden en een SLA durft af te sluiten met hoge penalties bij het breken van die SLA. Als je kantoorautomatisering eruit ligt een paar uur vanwege een fiber cut, vogelschijt op je straalzender e.d. dan heb je daar minder pijn van dan wanneer je primaire process stil komt te liggen.

[Exhar]

CORVETTE schreef op woensdag 27 maart 2013 @ 19:18:
Zijn de ervaringen met zgn Microwave niet goed ?

Er zijn wat bekende nadelen, maar ook voordelen. Zelfde geldt voor fibers: bekende nadelen, bekende voordelen.

Hangt dus heel erg van de applicatie af of een microwave een optie is of niet.

brederodekater schreef op donderdag 28 maart 2013 @ 08:39:
[...]


Wij hebben een aantal van dit soort links & zodra er een stormpje/regen/mist de kop op steekt kun je er donder op zeggen dat ze eruit klappen.

Hopen dat je een goede SLA refund policy op die link hebt, dan heb je wel een goede deal met zo'n 99.95% uptime garantie

De sneeuwstorm in Frankrijk (60cm ofzo?) op 12 maart leverde geen problemen op. Het kan dus wel. Overigens zit ik aan de leverancierskant (en niet de klantkant) van de link: de SLA kan mij dus nekken

DukeBox schreef op donderdag 28 maart 2013 @ 09:56:
[...]

Oh, nee, zo bedoel ik het helemaal niet. Het enige dat ik er eigenlijk mee wilde zeggen is dat een darkfiber vrijwel geen nadelen kent (anders dan de prijs), daardoor is het een betrouwbare oplossing.
Dat neemt niet weg dat er andere betrouwbare oplossingen kunnen zijn die veel economischer zijn.

Ik heb zelf radio ingezet op een aantal lokaties (31MHz licentie, 2,4GHz, 5GHz, 60Ghz) over afstanden van een paar honderd tot zo'n 7KM. Met snelheden van 3x2Mbit tot 450Mbit. Maar zonder (zoals eerder aangegeven) je hele netwerk erop in te stellen heb ik er nooit latency's uit gehaald die lager waren dan darkfibers van gelijke lengte. Ik vraag me dus heel erg af of het haalbaar is.

Sowieso zal je je netwerk moeten inregelen voor low-latency verbindingen. Of dat nou over een fiber gaat of microwave. Alleen zal 'n fiber absoluut goedkoper zijn dan een microwave - en soms betrouwbaarder.

Maar qua latency wint een microwave toch echt. Er is een reden daarom [..]Low-Latency MicroWave Connection Between Basildon and Frankfurt with a Latency of 4.74 Milliseconds Round Trip Market-to-Market traders een microwave zijn gaan gebruiken

[AndriesLouw]

Lijkt me niet verstandig om je SCADA/SAP buiten de deur te zetten, of het moet een replicatie zijn van een interne omgeving zijn die repliceert naar je externe. Een kleine hickup in de lijn kan er anders voor zorgen dat je meldingen mist, iets wat me alles behalve gewenst lijkt.

Hoe mooi het ook lijkt om alles te centraliseren, met dit soort systemen introduceer je liever niet te veel POF's.