Deployserver Technisch advies

[slijkie]

Beste mede-Tweakers,

Momenteel ben ik met een project bezig en ben een aantal opties aan het bekijken voor een Deploy-server.

De Deployserver zal content eruit knallen naar verschillende CDN POPs. Flinke aantallen. Hierdoor zal een simpele gbit poort niet voldoende zijn omdat het zo snel als mogelijk over moet. Heb gekeken naar een 10 Gbit poort (transit), echter zal dit ook een beperking zijn. Momenteel ben ik dus aan het kijken om een 100 gbps poort bij de AMSIX aan te vragen, peering, echter zijn ze erg goed verbonden met de grootste punten. Er een 1 gbps transit poortje (metered) ernaast zal prima als backup functioneren.

Echter zit ik nu met het idee, hoe ga ik dit doen, ik heb een full-rack beschikbaar, echter hoeft die van mij niet helemaal vol. Wat voor RAID is aan te raden voor Deployment? SSD's zijn een goed idee, mijn oog viel op de NVMe schijven (950 PRO NVMe). Ten tweede, zal 1 (flinke) server die 100 gbps redden? of is dit mogelijk in 2 te splitsen?

De data (kan 1 mb zijn of 1-2 gb file zijn) zo snel mogelijk op alle POPs uit te sturen.

Wat zijn jullie idee'n en suggesties hiervoor?

opgesomt:
- 48u rack
- Liefst minimaal aantal servers
- 100 gbps AMSIX peering poort
- 1 / 10 gbps transit poort (metered als backup)
- Opslag zo snel mogelijk om de volle snelheid te benutten.

Hoor graag jullie idee'n hierover.

Mvg,
slijkie

Extra's: (gevonden hw)
- m2 raid controllers

- Arista 7280R switch

[ Voor 7% gewijzigd door slijkie op 30-07-2016 12:58 . Reden: algemene aanpassingen. ]

[Frogmen]

Ben geen expert maar vindt het wel boeiend onderwerp. Waarom vanuit 1 punt alle POPs updaten? Via een hyarchisch systeem zal het sneller gaan voor mijn gevoel je POPs hebben tenslotte ook behoorlijk wat bandbreedte.

[RedShift]

Lees je in op de papers dat de Netflix engineers geproduceerd hebben.

[ik222]

Weet je precies wat de rol van AMS-IX is in het internet? Heb je überhaupt een eigen AS? Dan nog, je kunt daar wel een dikke poort hebben maar zult dan ook via AMS-IX nog moeten peeren met de partijen waar je verkeer heen moet. Als je aangesloten bent op AMS-IX heb je namelijk niet automatische een verbinding (via peering) met alle partijen die ook op AMS-IX zijn aangesloten. Oké, je hebt route-servers maar zeker de grote partijen zitten daar lang niet altijd op of geven een beperkte set routes via die servers door. Daarnaast als je met een bepaalde partij erg veel verkeer uitwisselt wil men vaak weer liever een directe peering hebben. De vraag is dus of je zicht hebt op waar je verkeer heen moet en via welke netwerken dat dan loopt.

Maar sowieso, één server i.c.m. een eigen 100Gbps AMS-IX poort + Transit link als "backup" klinkt niet als een hele logische en goed doordachte oplossing om het zacht uit te drukken... Ik denk dat je beter eens kan kijken wat een goede leverancier van colocation je kan aanbieden wat betreft connectiviteit.

[Uberprutser]

ik222 schreef op vrijdag 29 juli 2016 @ 13:40:
Maar sowieso, één server i.c.m. een eigen 100Gbps AMS-IX poort + Transit link als "backup" klinkt niet als een hele logische en goed doordachte oplossing om het zacht uit te drukken... Ik denk dat je beter eens kan kijken wat een goede leverancier van colocation je kan aanbieden wat betreft connectiviteit.

Wat hij zegt... AMS-IX klinkt heel geil maar zijn genoeg providers die onderling peeren die ook colo aanbieden (en sommigen ook 100Gbit). Verder mbt je storage; hier heb je optimized storage voor.

[ Voor 5% gewijzigd door Uberprutser op 29-07-2016 14:10 ]

[slijkie]

ik222 schreef op vrijdag 29 juli 2016 @ 13:40:
Weet je precies wat de rol van AMS-IX is in het internet? Heb je überhaupt een eigen AS? Dan nog, je kunt daar wel een dikke poort hebben maar zult dan ook via AMS-IX nog moeten peeren met de partijen waar je verkeer heen moet. Als je aangesloten bent op AMS-IX heb je namelijk niet automatische een verbinding (via peering) met alle partijen die ook op AMS-IX zijn aangesloten. Oké, je hebt route-servers maar zeker de grote partijen zitten daar lang niet altijd op of geven een beperkte set routes via die servers door. Daarnaast als je met een bepaalde partij erg veel verkeer uitwisselt wil men vaak weer liever een directe peering hebben. De vraag is dus of je zicht hebt op waar je verkeer heen moet en via welke netwerken dat dan loopt.

Maar sowieso, één server i.c.m. een eigen 100Gbps AMS-IX poort + Transit link als "backup" klinkt niet als een hele logische en goed doordachte oplossing om het zacht uit te drukken... Ik denk dat je beter eens kan kijken wat een goede leverancier van colocation je kan aanbieden wat betreft connectiviteit.

Weet je precies wat de rol van AMS-IX is in het internet?
Ja

Heb je überhaupt een eigen AS?
Nee, aanvraag is bezig bij RIPE. +/- 2 weken.

Dan nog, je kunt daar wel een dikke poort hebben maar zult dan ook via AMS-IX nog moeten peeren met de partijen waar je verkeer heen moet.
Klopt Veel partijen waar het heen moet staan er tussen (ca. 80%, rest kan via transit).

Als je aangesloten bent op AMS-IX heb je namelijk niet automatische een verbinding (via peering) met alle partijen die ook op AMS-IX zijn aangesloten. Oké, je hebt route-servers maar zeker de grote partijen zitten daar lang niet altijd op of geven een beperkte set routes via die servers door.
Klopt, heb nauw contact met de partijen (van die 80%), dus dat zal geen enkel probleem zijn. Meesten zitten op 10GE of 40GE.

Ik denk dat je beter eens kan kijken wat een goede leverancier van colocation je kan aanbieden wat betreft connectiviteit.
Kost meer. Zit ook Colocation in een Datacenter, de AMS-IX lijn zal daar geleverd worden. Scheelt heel veel in de kosten.

Tot slot, deze 1 (of 2) servertjes zullen niet de hele infrastructuur zijn. Maar zal deployment doen voor veel EU POPs. De Transit link is puur voor de het uitgezonderde verkeer. De redundancy zal van enkele andere 10GE transit servers zijn (managed & metered).

En zoals ik aangaf is dit een project, puur informatief alles op een rijtje te zetten, het lijkt mij goed haalbaar, maar we zullen zien.

Ballebek schreef op vrijdag 29 juli 2016 @ 14:09:
[...]

Wat hij zegt... AMS-IX klinkt heel geil maar zijn genoeg providers die onderling peeren die ook colo aanbieden (en sommigen ook 100Gbit). Verder mbt je storage; hier heb je optimized storage voor.

Klopt, maar in mijn geval zitten de meeste waarmee ik wil peeren verbonden met de AMS-IX. Voor mij zou NL-IX niks zijn. Vandaar de keuze.

Frogmen schreef op vrijdag 29 juli 2016 @ 13:04:
Ben geen expert maar vindt het wel boeiend onderwerp. Waarom vanuit 1 punt alle POPs updaten? Via een hyarchisch systeem zal het sneller gaan voor mijn gevoel je POPs hebben tenslotte ook behoorlijk wat bandbreedte.

Het is al redelijk hyarchisch. Stel er zijn 800 POPs van 25 netwerken. Via deze Deploy server zal het naar 25 servers doorgestuurd worden, liefst zo snel mogelijk naar alle 25. van die 25 zal het naar alle andere binnen hun eigen netwerk verstuurd worden. Als voorbeeld een 1 GB bestand die naar die 25 servers moet.

Stel dat die servers 10 GE hebben en niet belast zijn en in peering zijn via de AMS-IX (voor het voorbeeld dan). 4 Gbit per stuk beschikbaar voor elk (de ene meer dan de andere, maargoed gemiddeld). Zal het ongeveer 2 seconden duren om die 1 GB op alle 25 servers te hebben.

RedShift schreef op vrijdag 29 juli 2016 @ 13:40:
Lees je in op de papers dat de Netflix engineers geproduceerd hebben.

Thanks, had hier al deels over gelezen (Nginx enz) Ze gebruiken 4 CDN netwerken (als het er nu niet meer zijn). Zal er nog eens meer over lezen.

[ Voor 23% gewijzigd door slijkie op 29-07-2016 15:25 ]

[Rolfie]

slijkie schreef op vrijdag 29 juli 2016 @ 11:18:
Echter zit ik nu met het idee, hoe ga ik dit doen

Dit klinkt meer dat er geen architectuur is om dit even te doen. Je bent met techniek iets aan het oplossen, want gewoon in een architectuur verwerkt moet zijn.

Wat voor RAID is aan te raden voor Deployment? SSD's zijn een goed idee, mijn oog viel op de NVMe schijven (950 PRO NVMe).

Consumenten hardware gebruiken?

Ten tweede, zal 1 (flinke) server die 100 gbps redden? of is dit mogelijk in 2 te splitsen?

Volgens mij bestaan er nog niet eens 100 gbps netwerk kaarten

De data (kan 1 mb zijn of 1-2 gb file zijn) zo snel mogelijk op alle POPs uit te sturen.

Gewoon in memory bewaren? Als het zelf 10 keer groter is, kan het gewoon in geheugen verwerkt worden.

Wat zijn jullie idee'n en suggesties hiervoor?
....

Hoor graag jullie idee'n hierover.

Eerst back to the drawing board. Er moet hier eerst een design van zijn hoe de updates verwerkt worden want volgens mij is er dat nog niet eens. Daarna ga je eens kijken hoe je dit kunt bouwen en wat je werkelijke requirements zijn. Daarna ga je hardware selecteren en bestellen.

Extra's: (gevonden hw)
- m2 raid controllers

- Arista 7280R switch

Totaal nog niet relevant voor waar je mee bezig bent.

[RedShift]

Rolfie schreef op vrijdag 29 juli 2016 @ 16:42:
[...]

Eerst back to the drawing board. Er moet hier eerst een design van zijn hoe de updates verwerkt worden want volgens mij is er dat nog niet eens. Daarna ga je eens kijken hoe je dit kunt bouwen en wat je werkelijke requirements zijn. Daarna ga je hardware selecteren en bestellen.

[...]

Totaal nog niet relevant voor waar je mee bezig bent.

Jep. Een veel beter systeem zou via bittorrent zijn met verspreide nodes ipv. alles op één plaats. Zo doet Facebook het en werkt veel sneller dan gecentraliseerde deployment van content.

[slijkie]

Rolfie schreef op vrijdag 29 juli 2016 @ 16:42:
[...]

Dit klinkt meer dat er geen architectuur is om dit even te doen. Je bent met techniek iets aan het oplossen, want gewoon in een architectuur verwerkt moet zijn.

[...]

Consumenten hardware gebruiken?


[...]

Volgens mij bestaan er nog niet eens 100 gbps netwerk kaarten


[...]

Gewoon in memory bewaren? Als het zelf 10 keer groter is, kan het gewoon in geheugen verwerkt worden.


[...]


Eerst back to the drawing board. Er moet hier eerst een design van zijn hoe de updates verwerkt worden want volgens mij is er dat nog niet eens. Daarna ga je eens kijken hoe je dit kunt bouwen en wat je werkelijke requirements zijn. Daarna ga je hardware selecteren en bestellen.


[...]

Totaal nog niet relevant voor waar je mee bezig bent.

Dit klinkt meer dat er geen architectuur is om dit even te doen. Je bent met techniek iets aan het oplossen, want gewoon in een architectuur verwerkt moet zijn.

zit momenteel in de beginfase van het concept. Dus allemaal puur speculatief.

Consumenten hardware gebruiken?

Semi-consumenten hardware naar mijn mening, uiteraard ben ik alle opties aan het bekijken, Kijk voor al naar HP servers, HP heeft ook deze modules ervoor, die van Samsung zijn ca 250, die van HP zelf 380. Omdat het maar echt tijdelijke doorvoer storage is, kijk ik vooral naar de snelheid, die in dit geval gelijk 'lijkt'. Stel ik gebruik er 10. Dan kan ik er 10 bij hebben als er 1 stuk gaat (RAID Mirror) en gelijk vervangen. Als je mijn idee een beetje begrijpt. Uiteraard zou ik ook voor de Intel SSD DC P3608 Series kunnen gaan, maar dan ben je al dik 3500 euro per stuk kwijt. Dan denk ik bij mezelf, omdat ik mirroring raid in mijn hoofd heb, dan die andere optie 'misschien' kosten efficienter is.

Volgens mij bestaan er nog niet eens 100 gbps netwerk kaarten

Die zijn er zeker. QSFP kaarten, 1 van HP als voorbeeld. Maar er zijn er meerdere.

Gewoon in memory bewaren? Als het zelf 10 keer groter is, kan het gewoon in geheugen verwerkt worden.

Heb ik al te horen gekregen, ben er benieuwd naar. Moet nog even meer research doen over hoe dit in zijn werk gaat. Zou inderdaad een optie zijn.

Eerst back to the drawing board. Er moet hier eerst een design van zijn hoe de updates verwerkt worden want volgens mij is er dat nog niet eens. Daarna ga je eens kijken hoe je dit kunt bouwen en wat je werkelijke requirements zijn. Daarna ga je hardware selecteren en bestellen.

Zoals ik zei, het is momenteel nog op de drawing board. Puur speculatief. Vandaar dat alle kennis van mijn mede-tweakers van harte welkom is.

RedShift schreef op vrijdag 29 juli 2016 @ 17:57:
[...]

Jep. Een veel beter systeem zou via bittorrent zijn met verspreide nodes ipv. alles op één plaats. Zo doet Facebook het en werkt veel sneller dan gecentraliseerde deployment van content.

Kan je dit iets meer toelichten? Denk dat dit niet in mijn geval van toepassing zal zijn. Zover ik weer gebruikt Facebook voornamelijk CDN netwerken (Akamai als primaire). Het hele punt van CDN is load-balancing, is ook onmogelijk van 1 server. Echter dient de 'origin' 1 plek te zijn waarna het zich versprijd. Dat probeer ik dus te maken, de 'origin' server.

[Kettrick]

slijkie schreef op zaterdag 30 juli 2016 @ 12:56:
[...]

Kan je dit iets meer toelichten? Denk dat dit niet in mijn geval van toepassing zal zijn. Zover ik weer gebruikt Facebook voornamelijk CDN netwerken (Akamai als primaire). Het hele punt van CDN is load-balancing, is ook onmogelijk van 1 server. Echter dient de 'origin' 1 plek te zijn waarna het zich versprijd. Dat probeer ik dus te maken, de 'origin' server.

Facebook gebruikt(e?) een torrent-based systeem om hun complete binary ( zo uit mijn hoofd was het in die tijd 1,5gb ) naar alle servers te pushen. Dit gebeurde dus als onderdeel van de release intern, niet om publieke content te synchroniseren, daarvoor gebruikten ze uiteraard een cdn.

Of dit nog steeds het geval is, geen idee, het filmpje waar die info uit komt staat wel op youtube maar is inmiddels een aantal jaren oud.

BTSync zou iets in die richting zijn, maar je zou ook een bestand op S3 kunnen zetten en deze middels torrents downloaden ?.

[slijkie]

Kettrick schreef op zaterdag 30 juli 2016 @ 13:15:
[...]


Facebook gebruikt(e?) een torrent-based systeem om hun complete binary ( zo uit mijn hoofd was het in die tijd 1,5gb ) naar alle servers te pushen. Dit gebeurde dus als onderdeel van de release intern, niet om publieke content te synchroniseren, daarvoor gebruikten ze uiteraard een cdn.

Of dit nog steeds het geval is, geen idee, het filmpje waar die info uit komt staat wel op youtube maar is inmiddels een aantal jaren oud.

BTSync zou iets in die richting zijn, maar je zou ook een bestand op S3 kunnen zetten en deze middels torrents downloaden ?.

Interesant, lees er inderdaad het 1 en anders over. echter zal dit niet mogelijk zijn bij deze uitdaging. De servers waar de files heen 'gepushed' worden zijn niet in eigen beheer, dit kan alleen via FTP of rsync. Kan dus niet p2p software hierop knallen.

[Rolfie]

slijkie schreef op zaterdag 30 juli 2016 @ 12:56:
Semi-consumenten hardware naar mijn mening, uiteraard ben ik alle opties aan het bekijken, Kijk voor al naar HP servers, HP heeft ook deze modules ervoor, die van Samsung zijn ca 250, die van HP zelf 380. Omdat het maar echt tijdelijke doorvoer storage is, kijk ik vooral naar de snelheid, die in dit geval gelijk 'lijkt'. Stel ik gebruik er 10. Dan kan ik er 10 bij hebben als er 1 stuk gaat (RAID Mirror) en gelijk vervangen. Als je mijn idee een beetje begrijpt. Uiteraard zou ik ook voor de Intel SSD DC P3608 Series kunnen gaan, maar dan ben je al dik 3500 euro per stuk kwijt. Dan denk ik bij mezelf, omdat ik mirroring raid in mijn hoofd heb, dan die andere optie 'misschien' kosten efficienter is.

De HP prijs heeft natuurlijk een redenen. Het is getest in die machine, en je weet dat het werkt en getest is door HP. De P3608 heeft ook een redenen waarom die zo duur is....
Vergeet niet dat HP niet altijd vreemde disks aan zijn raid controllers wilt hebben. En waar wil je raid op draaiem?

Voor de 100Gb kaart... Ik zou veel eerder de load gaan verdelen over meerdere servers. Om 1 server 100Gb te laten generen, is extreem zwaar. Maar om 10 servers 10Gb te distribueren is wel goed te doen, al moet je je hiebij ook niet vergissen hoeveel power dit kan kosten op de server en software. Het wel eens een stuk beter kunnen performen om 10 fysieke servers te hebben, waarop op iedere servers 10 virtuele servers draaien. servers draaien die allemaal 1Gb aan verkeer kunnen verwerken. Zit je ook op 100Gb, maar wel veel meer schaalbaar. Je kunt er gewoon een host bij zetten, vol automatisch.
Als alle servers ook nog eens 10Gb RAMdisk hebben voor je data moet je dit zonder moeite goed kunnen verdelen Eventueel intern eerst via een p2p distributie verdelen. Memory is goed betaalbaar.

Natuurlijk even niet vergeten een goede firewall, die 100Gb aan kan , of juist weer per bouwblok.... en IP adressen.....

Alles hangt natuurlijk een beetje van je exacte requirements af, hoe vaak je de data moet updaten. Hoe snel dit gedaan moet worden. En hoe groot de data dan is.
Persoonlijk zou ik voor een bouwblok gaan. Gewoon 1 fysieke servers, aansluiten op 2 * 10Gb, en hierop x virtuele machine draaien. Cache bewaren of op enterprise SSD's of in memory (voorkeur). Firewalling op deze machine laten draaien zodat het een autonoom bouwblok is.

Anders misschien nog cloud een goede oplossing. Via Amazone, kan je bandbreedte genoeg regelen, en je kunt je servers allemaal scripten. Gewoon 100 servers laten aanmaken, automatisch Configureren, en daarna update aftrappen. Hierna weer weg gooien of uitzetten.

Kosten technisch zeer efficient, geen investeringen nodig en volledig schaalbaar zoals jij het zelf nooit kan bouwen.

[Wim-Bart]

Kettrick schreef op zaterdag 30 juli 2016 @ 13:15:
[...]


Facebook gebruikt(e?) een torrent-based systeem om hun complete binary ( zo uit mijn hoofd was het in die tijd 1,5gb ) naar alle servers te pushen. Dit gebeurde dus als onderdeel van de release intern, niet om publieke content te synchroniseren, daarvoor gebruikten ze uiteraard een cdn.

Of dit nog steeds het geval is, geen idee, het filmpje waar die info uit komt staat wel op youtube maar is inmiddels een aantal jaren oud.

BTSync zou iets in die richting zijn, maar je zou ook een bestand op S3 kunnen zetten en deze middels torrents downloaden ?.

Ja maar Facebook heeft er wel een aantal PureStorage arrays onder hangen tegenwoordig om de performance te kunnen halen.

[ik222]

Let ook even op hoe je de routing wilt gaan doen als je met een eigen AS, een dikke AMS-IX aansluiting en een transit verbinding wilt gaan werken. Je zult een router nodig hebben die BGP gaat doen, de benodigde interface poorten heeft en de bandbreedte kan verwerken.

Maar ik blijf erbij dat ik het een rare combinatie / design vind. Een enkele server en dan dergelijke connectiviteit. Ik bedoel 100Gbps poorten op AMS-IX op hebben zelfs vrij grote hosters en ISP's vaak nog niet eens, die zie je eigenlijk alleen nog bij de hele grote jongens. Ik heb zelf echt de indruk dat je een bepaalde requirement op een verkeerde manier aan het invullen bent.

[ Voor 41% gewijzigd door ik222 op 30-07-2016 21:44 ]

[PerfectPC]

ik222 schreef op zaterdag 30 juli 2016 @ 21:39:
Ik heb zelf echt de indruk dat je een bepaalde requirement op een verkeerde manier aan het invullen bent.

Welke requirement?

[CAPSLOCK2000]

slijkie schreef op vrijdag 29 juli 2016 @ 11:18:
Echter zit ik nu met het idee, hoe ga ik dit doen, ik heb een full-rack beschikbaar, echter hoeft die van mij niet helemaal vol. Wat voor RAID is aan te raden voor Deployment? SSD's zijn een goed idee, mijn oog viel op de NVMe schijven (950 PRO NVMe). Ten tweede, zal 1 (flinke) server die 100 gbps redden? of is dit mogelijk in 2 te splitsen?

Met 1 server ga je die 100 gbps niet vullen. In theorie kan het wel en als je maar genoeg geld uitgeeft zal het wel lukken, maar dat lijkt me niet de beste oplossing. 100gpbs netwerk en 950 Pro SSD'tje is niet echt een gebruikelijke combinatie.
Met een paar kleinere servers haal je waarschijnlijk dezelfde performance tegen een lagere prijs, als je toch ruimte in je rack over hebt zou ik daar gebruik van maken. Daarbij is het beter voor je beschikbaarheid om niet alles via 1 server te doen, als die stuk gaat heb je niks meer.

[jvanhambelgium]

Qua storage/IOPS zou ik me allesinds niet teveel zorgen maken. Als je "een set" files gaat repliceren (telkens dezelfde naar vb 25 onderliggende machines) zal het bestand 1x ingelezen worden en vervolgens eigenlijk uit geheugen/cache gefetched gaan worden.

Je zou met Nginx of Varnish aan de slag kunnen voor het stuk rond caching moest dit in je architectuur passen.
Als je dan 64GB of 128GB RAM voorziet in een deploy-node kan je aan een aardig tempo static content serveren.

Mah bon, wij hebben hier geen idee waarover het eigenlijk gaat, wat de content eigenlijk is. Dat ga je allemaal moeten uitwerken en hierop iets ontwerpen.

[slijkie]

Rolfie schreef op zaterdag 30 juli 2016 @ 17:29:
[...]


De HP prijs heeft natuurlijk een redenen. Het is getest in die machine, en je weet dat het werkt en getest is door HP. De P3608 heeft ook een redenen waarom die zo duur is....
Vergeet niet dat HP niet altijd vreemde disks aan zijn raid controllers wilt hebben. En waar wil je raid op draaiem?

Voor de 100Gb kaart... Ik zou veel eerder de load gaan verdelen over meerdere servers. Om 1 server 100Gb te laten generen, is extreem zwaar. Maar om 10 servers 10Gb te distribueren is wel goed te doen, al moet je je hiebij ook niet vergissen hoeveel power dit kan kosten op de server en software. Het wel eens een stuk beter kunnen performen om 10 fysieke servers te hebben, waarop op iedere servers 10 virtuele servers draaien. servers draaien die allemaal 1Gb aan verkeer kunnen verwerken. Zit je ook op 100Gb, maar wel veel meer schaalbaar. Je kunt er gewoon een host bij zetten, vol automatisch.
Als alle servers ook nog eens 10Gb RAMdisk hebben voor je data moet je dit zonder moeite goed kunnen verdelen Eventueel intern eerst via een p2p distributie verdelen. Memory is goed betaalbaar.

Natuurlijk even niet vergeten een goede firewall, die 100Gb aan kan , of juist weer per bouwblok.... en IP adressen.....

Alles hangt natuurlijk een beetje van je exacte requirements af, hoe vaak je de data moet updaten. Hoe snel dit gedaan moet worden. En hoe groot de data dan is.
Persoonlijk zou ik voor een bouwblok gaan. Gewoon 1 fysieke servers, aansluiten op 2 * 10Gb, en hierop x virtuele machine draaien. Cache bewaren of op enterprise SSD's of in memory (voorkeur). Firewalling op deze machine laten draaien zodat het een autonoom bouwblok is.

Anders misschien nog cloud een goede oplossing. Via Amazone, kan je bandbreedte genoeg regelen, en je kunt je servers allemaal scripten. Gewoon 100 servers laten aanmaken, automatisch Configureren, en daarna update aftrappen. Hierna weer weg gooien of uitzetten.

Kosten technisch zeer efficient, geen investeringen nodig en volledig schaalbaar zoals jij het zelf nooit kan bouwen.

Goede info, zal er eens naar kijken. Echter 100 vm's. Er word 1 file geupload naar ftp bijvoorbeeld. Hoe snel is diezelfde file naar de 20-30 endpoints? En veel te managen.

Firewall word inderdaad naar gekeken. En tevens heb ik veel naar die cloud oplossingen gekeken maar heb zo mijn twijvels over hoe snel ze daadwerkelijk zijn. En hoge kosten om ze aan te laten en 'beschikbaar'. Het is niet voor eigen geplanned gebruik. Maar on-demand voor clienten.

ik222 schreef op zaterdag 30 juli 2016 @ 21:39:
Let ook even op hoe je de routing wilt gaan doen als je met een eigen AS, een dikke AMS-IX aansluiting en een transit verbinding wilt gaan werken. Je zult een router nodig hebben die BGP gaat doen, de benodigde interface poorten heeft en de bandbreedte kan verwerken.

Maar ik blijf erbij dat ik het een rare combinatie / design vind. Een enkele server en dan dergelijke connectiviteit. Ik bedoel 100Gbps poorten op AMS-IX op hebben zelfs vrij grote hosters en ISP's vaak nog niet eens, die zie je eigenlijk alleen nog bij de hele grote jongens. Ik heb zelf echt de indruk dat je een bepaalde requirement op een verkeerde manier aan het invullen bent.

Klopt. Ziggo heeft 2 x 200 gbps. Kleinere partijen minder. Zit inderdaad te kijken om het over meer server te splitten eventueel. Misschien 4 x 25 gbps. Omdat er toch 20-30 endpoints zijn. Mocht 1 van de 4 falen zijn er nog 3 die het overnemen. Alleen ik zie niemand dit perse doen. Vandaar dat de uitdaging voor mij des te leuker is. Wel zie ik mensen bepaalde snelheden wel op 1 server halen. Dus mogelijk is er.

CAPSLOCK2000 schreef op zondag 31 juli 2016 @ 12:47:
[...]


Met 1 server ga je die 100 gbps niet vullen. In theorie kan het wel en als je maar genoeg geld uitgeeft zal het wel lukken, maar dat lijkt me niet de beste oplossing. 100gpbs netwerk en 950 Pro SSD'tje is niet echt een gebruikelijke combinatie.
Met een paar kleinere servers haal je waarschijnlijk dezelfde performance tegen een lagere prijs, als je toch ruimte in je rack over hebt zou ik daar gebruik van maken. Daarbij is het beter voor je beschikbaarheid om niet alles via 1 server te doen, als die stuk gaat heb je niks meer.

Goed punt, ik ben het serieus aan het bekijken.

jvanhambelgium schreef op zondag 31 juli 2016 @ 13:08:
Qua storage/IOPS zou ik me allesinds niet teveel zorgen maken. Als je "een set" files gaat repliceren (telkens dezelfde naar vb 25 onderliggende machines) zal het bestand 1x ingelezen worden en vervolgens eigenlijk uit geheugen/cache gefetched gaan worden.

Je zou met Nginx of Varnish aan de slag kunnen voor het stuk rond caching moest dit in je architectuur passen.
Als je dan 64GB of 128GB RAM voorziet in een deploy-node kan je aan een aardig tempo static content serveren.

Mah bon, wij hebben hier geen idee waarover het eigenlijk gaat, wat de content eigenlijk is. Dat ga je allemaal moeten uitwerken en hierop iets ontwerpen.

Soort van eigen local CDN en daarna daaruit deployen bedoel je? Zo vat ik je op.

[jvanhambelgium]

slijkie schreef op zondag 31 juli 2016 @ 13:28:
[...]


Soort van eigen local CDN en daarna daaruit deployen bedoel je? Zo vat ik je op.

Je moet uiteindelijk een hierarchie gaan opbouwen om je data te gaan repliceren naar de volgende laag, die gaat het weer verder pushen/laten ophalen door onderliggende 3e laag etc.

Met Varnish kan je wel wat als deel van je oplossing.

http://thenewstack.io/sin...rnish-create-private-cdn/

[Bigs]

Je hebt een 100GBit AMS-IX poort voor ogen, maar kunt volgens je TS volstaan met een 1 of 10Gbit poort als backup. Hier klopt echt iets niet.

Het lijkt me dat je sowieso zelf ook een architectuur verdeeld over meerdere datacenters wilt opzetten als je op de schaal opereert waarvan wij vermoeden dat je opereert (want ja er zijn nogal wat onduidelijkheden).

[Rolfie]

slijkie schreef op zondag 31 juli 2016 @ 13:28:
Goede info, zal er eens naar kijken. Echter 100 vm's. Er word 1 file geupload naar ftp bijvoorbeeld. Hoe snel is diezelfde file naar de 20-30 endpoints? En veel te managen.

Juist niet.... Als je er goed over nadenkt. Je denkt vanuit techniek, en daar moet je helemaal nog niet over nadenken.....

Misschien lullig om te zeggen, je bent niet de juiste man voor dit stukje.

Firewall word inderdaad naar gekeken. En tevens heb ik veel naar die cloud oplossingen gekeken maar heb zo mijn twijvels over hoe snel ze daadwerkelijk zijn. En hoge kosten om ze aan te laten en 'beschikbaar'. Het is niet voor eigen geplanned gebruik. Maar on-demand voor clienten.

Moet niet uitmaken....
Maar dat zijn juist requirements die van belang zijn.
Hoe lang van te voren krijg dit je verzoek?
Hoe snel moet het upload worden als je de file aangeleverd hebt.
Naar hoeveel endpoints moet dit verdeeld worden?

Maar even weer even terug naar het begin......

Denk in bouwblokken....

We hebben een Database.
We hebben een Controller.
We hebben x workers.

De controller maakt, en beheerd de jobs in de database.
In de database worden de jobs bij gehouden voor de workers.
De Workers controleren de database voor opdrachten.
Denk bijvoorbeeld voor een opdracht: File X moet via FTP naar locatie A geupload worden.
De controller weet hoeveel hoeveel workers er zijn, en dan de jobs verdelen.
Denk nu bij het aantal workers tussen de 1 - X.... Het aantal maakt in eens niet meer uit.
Ofwel je kan heel gemakkelijk een scale-out doen Of je dit nu maakt voor 10 of 100 workers, dit maakt niet meer uit. Alleen je database of controller moet iets krachtiger worden.

Je moet nog wel even over het 1 en ander nadenken.... Result uploaden, en file distributie....

Voor cloud er bij.... Er is gewoon een job die machines opstart en weer kan afsluiten. Of een template kopieren.

Hier heb je eigenlijn een basis architectuur die schaalbaar is, en betaalbaar is. Heb je meer nodig, dan zet je meer workers in.

Klopt. Ziggo heeft 2 x 200 gbps. Kleinere partijen minder. Zit inderdaad te kijken om het over meer server te splitten eventueel. Misschien 4 x 25 gbps. Omdat er toch 20-30 endpoints zijn. Mocht 1 van de 4 falen zijn er nog 3 die het overnemen. Alleen ik zie niemand dit perse doen. Vandaar dat de uitdaging voor mij des te leuker is. Wel zie ik mensen bepaalde snelheden wel op 1 server halen. Dus mogelijk is er.

De meeste zullen 100GB gebruiken voor lagere latency. Vergeet niet dat als je werkelijk 100Gb wilt verstouwen, dan je extreem veel power nodig gaat hebben op de server. Zelf voor 10Gb moeten je machines echt zwaar zijn, en alle code geoptimaliseerd. Je moet namelijk nu ook nog iets verzinnen hoe je alles gaat beheren. Dit wil je automatisch en zeker niet met de hand gaan regenen.
(stap uit de techniek, en in de architectuur).


Ik zou ook nog eens eerst heelgoed gaan nadenken hoe je dit wilt bouwen. Ik verwacht nooit dat je dit zelf betaalbaar kan hosten. Cloud is hier een veel betere oplossing voor.
Als je alleen al even berekend wat een dual 100Gb POP kost,AS neer zetten, redudante switches, Firewalls en hardware. Daar kan je een cloud oplossing heel lang voor laten draaien. En de kennis om dit te beheren, vergeet niet dat jij ook op vakantie gaat, of misschien over 2 maanden ergens anders gaat werken. En wat je nu neer gezet, beheer je niet even. Hier moet je wel kennis van hebben.
Dit is juist het voordeel van cloud, je hoeft over al deze dingen niet na te denken. Je neemt gewoon af, wat je nodig hebt. Pay Per Use. Dit is juist de redenen waarom grote bedrijven cloud voor dit nemen.

[slijkie]

Rolfie schreef op zondag 31 juli 2016 @ 15:21:
[...]
Juist niet.... Als je er goed over nadenkt. Je denkt vanuit techniek, en daar moet je helemaal nog niet over nadenken.....

Misschien lullig om te zeggen, je bent niet de juiste man voor dit stukje.


[...]

Moet niet uitmaken....
Maar dat zijn juist requirements die van belang zijn.
Hoe lang van te voren krijg dit je verzoek?
Hoe snel moet het upload worden als je de file aangeleverd hebt.
Naar hoeveel endpoints moet dit verdeeld worden?

Maar even weer even terug naar het begin......

Denk in bouwblokken....

We hebben een Database.
We hebben een Controller.
We hebben x workers.

De controller maakt, en beheerd de jobs in de database.
In de database worden de jobs bij gehouden voor de workers.
De Workers controleren de database voor opdrachten.
Denk bijvoorbeeld voor een opdracht: File X moet via FTP naar locatie A geupload worden.
De controller weet hoeveel hoeveel workers er zijn, en dan de jobs verdelen.
Denk nu bij het aantal workers tussen de 1 - X.... Het aantal maakt in eens niet meer uit.
Ofwel je kan heel gemakkelijk een scale-out doen Of je dit nu maakt voor 10 of 100 workers, dit maakt niet meer uit. Alleen je database of controller moet iets krachtiger worden.

Je moet nog wel even over het 1 en ander nadenken.... Result uploaden, en file distributie....

Voor cloud er bij.... Er is gewoon een job die machines opstart en weer kan afsluiten. Of een template kopieren.

Hier heb je eigenlijn een basis architectuur die schaalbaar is, en betaalbaar is. Heb je meer nodig, dan zet je meer workers in.


[...]

De meeste zullen 100GB gebruiken voor lagere latency. Vergeet niet dat als je werkelijk 100Gb wilt verstouwen, dan je extreem veel power nodig gaat hebben op de server. Zelf voor 10Gb moeten je machines echt zwaar zijn, en alle code geoptimaliseerd. Je moet namelijk nu ook nog iets verzinnen hoe je alles gaat beheren. Dit wil je automatisch en zeker niet met de hand gaan regenen.
(stap uit de techniek, en in de architectuur).


Ik zou ook nog eens eerst heelgoed gaan nadenken hoe je dit wilt bouwen. Ik verwacht nooit dat je dit zelf betaalbaar kan hosten. Cloud is hier een veel betere oplossing voor.
Als je alleen al even berekend wat een dual 100Gb POP kost,AS neer zetten, redudante switches, Firewalls en hardware. Daar kan je een cloud oplossing heel lang voor laten draaien. En de kennis om dit te beheren, vergeet niet dat jij ook op vakantie gaat, of misschien over 2 maanden ergens anders gaat werken. En wat je nu neer gezet, beheer je niet even. Hier moet je wel kennis van hebben.
Dit is juist het voordeel van cloud, je hoeft over al deze dingen niet na te denken. Je neemt gewoon af, wat je nodig hebt. Pay Per Use. Dit is juist de redenen waarom grote bedrijven cloud voor dit nemen.

Alright, ik snap je punt, meerder malen aan gegeven dat ik niet in de juiste richting denk. Zal de vraag dan anders proberen te stellen, mocht je tijd & zin hebben om dat te beantwoorden.

1 visueel punt, zie het als een FTP upload in dit geval. je hebt een file van 2 GB. je upload deze erop. En dan start.

Hoe zou jij dit doen (even zonder de pay-as-you-go cloud).

Het moet naar 25 FTP servers versprijd over Europa. Je kan niks op die servers installen want het zijn niet jou servers. Wat is de allersnelste manier die jij kan bedenken qua tijd. liefst naar alle 25 in enkele seconden.

Dat is eigenlijk het enige en primaire werk dat de server(s) uit zullen voeren.

Benieuwd in welke richting je op gaat

[knutsel smurf]

Ik kan wel een mooie dc netwerk oplossing bedenken maar wat is je budget?

Als je kijkt naar het prijsverschil tussen een 100gbps met een fallback naar 10gb. En redundant 4x10gbps zit je op bijna 50%.

Dit komt omdat je zowiezoo minimaal 4X 100gbps poorten gaat nodig hebben.
Je kan even server niet heel makkelijk dual homen met 1x100 en 1x10. En 100gb poorten gaan per 2.

Dus als je 2x een TOR switch neemt met 10 of 40gb uplinks ben je veel goedkoper en ook echt veel.

Laten we er van uit gaan dat het een 2gb file is, dan heb je dit met 10gbps binnen een paar seconden verplaatst naar 1 node. Mits de server hardware en netwerk het aan beide kanten dit aan kan.

Stel jij hebt 4 servers in je rack welke alle 4 dit bestand hebben heb hypothetisch dit binnen 10 seconden op 4 van de 25 nodes. En in 20 seconden op 8 maar als je de 4 nieuwe ook kan gebruiken dan staat het in 20 seconden op 12 en in net iets meer dan 30 op alle 25.

Let op dit heeft een hoop voorwaarden. Het is niet zo simpel als ik hier nu voorschets.

Maar nu komt de grote vraag kan je de hardware aan de ontvanger ook bepalen?
En zou je eventueel als het bestand bij de eerste ontvanger is gekomen automatisch naar andere kunnen repliceren?

Daarbij als je dit via een publiek netwerk wilt doen zoals ams-ix dan zal je zoals al reeds gezegt door andere aan de security moeten denken.

Waar ik dus aan zit te denken is dat je het beste af bent om een grote fabric te creëren, met behulp van SD-WAN oplossingen etc. Kijk hierbij naar AVAYA fabric en kijk vooral naar nutanix server hardware.

Hiervoor moet je wel de optie hebben om in alle 25 pop's een fabric attach unit te plaatsen.

Ik kan je vanuit de vendor wel wat adviezen geven omtrent oplossingen die doen wat je wilt maar laten we dat dan even via een pm of email doen.

[johnkeates]

Als je data snel wil versturen, dan doe je dat vanuit RAM. Sneller dan dat wordt het niet, en als je ~192GB RAM hebt kan je daar vast wel 100GB van gebruiken puur voor je send/receive buffers. Zo duur is RAM niet, en als je een beetje goed shopt heb je voor 1000 euro meer dan genoeg om je 100Gbps pijp 10x te vullen.

Als je vanaf 1 server naar 25 andere servers instant wil uploaden, en je alvast weet hoe groot je uploads gaan zijn, dan hoef je dus alleen nog maar uit te rekenen wat voor verbinding en wat voor serveerhardware je nodig hebt. 16Gbit over een 40Gbit lijn gaat best snel, als je het nog sneller wil doen met je 100Gbit lijn, dan kan dat, maar dan is het misschien verstandiger om 2 of 4 servers te pakken, onderling met iets als Infiniband te verbinden en dan eerst lokaal in RAM alles hebben staan. Als je in 2 seconden standby staat voor een upload en dan vanaf 4 servers met ±10Gbit kan uploaden kan je in ongeveer 10 seconden 25 servers wel van 2GB data voorzien.

Al met al lijkt me hier wel een XY-probleem van toepassing te zijn, wat probeer je daadwerkelijk op te lossen? Die data komt waarschijnlijk ergens vandaan, of wordt eerst verzameld over een langere periode, wat eigenlijk betekent dat je helemaal geen burst hoeft te doen maar zelfs met een simpele RBD al klaar bent...

[Rolfie]

slijkie schreef op maandag 01 augustus 2016 @ 08:35:
Alright, ik snap je punt, meerder malen aan gegeven dat ik niet in de juiste richting denk. Zal de vraag dan anders proberen te stellen, mocht je tijd & zin hebben om dat te beantwoorden.

1 visueel punt, zie het als een FTP upload in dit geval. je hebt een file van 2 GB. je upload deze erop. En dan start.

Hoe zou jij dit doen (even zonder de pay-as-you-go cloud).

Het moet naar 25 FTP servers versprijd over Europa. Je kan niks op die servers installen want het zijn niet jou servers. Wat is de allersnelste manier die jij kan bedenken qua tijd. liefst naar alle 25 in enkele seconden.

Dat is eigenlijk het enige en primaire werk dat de server(s) uit zullen voeren.

Benieuwd in welke richting je op gaat

Opzich redelijk simpel.... Maar om het te beschrijven is een stuk lastiger. Een flow diagram of tekeningen zijn hierin een stuk gemakkelijker.

Maar dezelfde architectuur: Database, Controller, Worker.
De working is gewoon een script wat "iets" aftrapt. Er kunnen meerdere workers op 1 server draaien. Hoe is een tweede. Dit kan dus een FTP, RSYNC CURL SCP commando zijn.

De controller weet dat er bijvoorbeeld 10 workers zijn, verdeelt over 5 servers. Dus 2 " workers per server.

De controller zorg er dat een worker altijd 2 jobs actief heeft in de database als er een upload gedaan moet worden.

De eerst job op een server, moet checken of de benodigde source file aanwezig is, zo niet, kopieer deze van locatie X, en plaat deze op een RAM drive op de server voor optimale snelheid.

Hierna lees "een" worker uit de database zijn opdrachten uit.
job1: file X via FTP upload moet worden naar host: ftp.tweakers.nl met userid en password en de file moet op locatie Y neer gezet worden.
job2: file X via FTP upload moet worden naar host: ftp.tweakers.be met userid en password en de file moet op locatie Y neer gezet worden.

De worker gaat job 1 uitvoeren, en zal hierna het resultaat uploaden in de database. En de worker vraagt meteen een volgende job aan, welke hij meteen gaat uitvoeren.

Ondertussen ziet de controller ziet dat job 1 gedaan is, en zet meteen een nieuwe jobs gereed, zodat deze ook uitgevoerd kan worden. Mocht een worker hangen, dan zal deze geen nieuwe opdrachten te verwerken krijgen. Aangezien in de database nog steeds de jobs niet op completed staan.
Is een worker langer bezig, omdat bijvoorbeeld andere FTP server maar een 10Mb verbinding heeft, maakt niet uit. Hij verwerkt dan gewoon minder jobs. Vergeet niet dat jij misschien wel een 100Gb verbinding hebt, als de andere kant dit niet heeft, zal jij hier rekening mee moeten houden.

Je moet hierbij nog heel wat fout afhandelingen programmeren en monitoring. Maar deze architectuur is schaalbaar. Immers een worker is een bouwblok, die ergens staat. Of dit er 10 of 100 zijn, maakt niet uit.
En misschien kan je nog wel meer intelligentie bouwen in de database, maar heb ik nu niet voldoende kennis van. Of kun je dingen op een andere manier nog beter doen.

Misschien kan een worker wel meerdere jobs tegelijkertijd afhandelen, maar dit maakt fout afhandeling alleen maar complexer. Ik zou dan eerder gaan voor meerdere workers.

En vergeet niet dat, als jij hier een dienst van maakt voor je klanten, je redelijk moet nadenken over controles monitoring en schaalbaarheid.
Zomaar een script aftrappen, is altijd gedoemd tot mislukking, want er zal altijd ergens wel iets verkeerd gaat, waar je dus rekening mee moet houden.

Maar het gaat om het idee.....

Als je er eens over wilt brainstormen, stuur dan een DM.


.

[slijkie]

knutsel smurf schreef op maandag 01 augustus 2016 @ 14:37:
Ik kan wel een mooie dc netwerk oplossing bedenken maar wat is je budget?

Als je kijkt naar het prijsverschil tussen een 100gbps met een fallback naar 10gb. En redundant 4x10gbps zit je op bijna 50%.

Dit komt omdat je zowiezoo minimaal 4X 100gbps poorten gaat nodig hebben.
Je kan even server niet heel makkelijk dual homen met 1x100 en 1x10. En 100gb poorten gaan per 2.

Dus als je 2x een TOR switch neemt met 10 of 40gb uplinks ben je veel goedkoper en ook echt veel.

Laten we er van uit gaan dat het een 2gb file is, dan heb je dit met 10gbps binnen een paar seconden verplaatst naar 1 node. Mits de server hardware en netwerk het aan beide kanten dit aan kan.

Stel jij hebt 4 servers in je rack welke alle 4 dit bestand hebben heb hypothetisch dit binnen 10 seconden op 4 van de 25 nodes. En in 20 seconden op 8 maar als je de 4 nieuwe ook kan gebruiken dan staat het in 20 seconden op 12 en in net iets meer dan 30 op alle 25.

Let op dit heeft een hoop voorwaarden. Het is niet zo simpel als ik hier nu voorschets.

Maar nu komt de grote vraag kan je de hardware aan de ontvanger ook bepalen?
En zou je eventueel als het bestand bij de eerste ontvanger is gekomen automatisch naar andere kunnen repliceren?

Daarbij als je dit via een publiek netwerk wilt doen zoals ams-ix dan zal je zoals al reeds gezegt door andere aan de security moeten denken.

Waar ik dus aan zit te denken is dat je het beste af bent om een grote fabric te creëren, met behulp van SD-WAN oplossingen etc. Kijk hierbij naar AVAYA fabric en kijk vooral naar nutanix server hardware.

Hiervoor moet je wel de optie hebben om in alle 25 pop's een fabric attach unit te plaatsen.

Ik kan je vanuit de vendor wel wat adviezen geven omtrent oplossingen die doen wat je wilt maar laten we dat dan even via een pm of email doen.

Budget is niet perse vastgesteld, hoe meer kostenbesparend hoe beter, maar uiteraard niet voor een dubbeltje op de 1e rang.

Denk dat ik het woordje 'backup' niet had moeten gebruiken. Die 10 gbit is er naast omdat het Transit is ipv Peering. 80% waarnaar het toe gaat is aangesloten via Peering, vandaar. Qua backup is het eerder een rented solution in een heel ander DC. Ook een 10 gbit transit, maargoed, performace zal dan zakken indien er een failure is, maar het blijft werken.

Wat bedoelde je precies met een TOR switch, die volg ik even niet.

Dus je stelt voor 4 servers, allemaal 10 gbps. 1 file direct naar elkaar toe en daarna eruit. zou kunnen, echter komt de totale deploy-tijd naar alle 25 uit op meer dan een minuut denk ik zo. Ik probeer het het liefst onder de 10 sec te houden. (indien mogelijk).

De hardware aan ontvangende kant haalt dit wel. Die hebben 10 gbps minimaal, meestal meer. (en hw dat dat aan kan). Enige pure pech zou zijn dat die lijn in die 'aantal seconden' volgeplempt is met andere incoming data. Dat zou puur toeval zijn, maar dan duurt die enkele keer maar wat langer.

Die 25 pop's zijn niet van mij, en kan er niks plaatsen. Is dus niet mogelijk.

johnkeates schreef op maandag 01 augustus 2016 @ 14:50:
Als je data snel wil versturen, dan doe je dat vanuit RAM. Sneller dan dat wordt het niet, en als je ~192GB RAM hebt kan je daar vast wel 100GB van gebruiken puur voor je send/receive buffers. Zo duur is RAM niet, en als je een beetje goed shopt heb je voor 1000 euro meer dan genoeg om je 100Gbps pijp 10x te vullen.

Als je vanaf 1 server naar 25 andere servers instant wil uploaden, en je alvast weet hoe groot je uploads gaan zijn, dan hoef je dus alleen nog maar uit te rekenen wat voor verbinding en wat voor serveerhardware je nodig hebt. 16Gbit over een 40Gbit lijn gaat best snel, als je het nog sneller wil doen met je 100Gbit lijn, dan kan dat, maar dan is het misschien verstandiger om 2 of 4 servers te pakken, onderling met iets als Infiniband te verbinden en dan eerst lokaal in RAM alles hebben staan. Als je in 2 seconden standby staat voor een upload en dan vanaf 4 servers met ±10Gbit kan uploaden kan je in ongeveer 10 seconden 25 servers wel van 2GB data voorzien.

Al met al lijkt me hier wel een XY-probleem van toepassing te zijn, wat probeer je daadwerkelijk op te lossen? Die data komt waarschijnlijk ergens vandaan, of wordt eerst verzameld over een langere periode, wat eigenlijk betekent dat je helemaal geen burst hoeft te doen maar zelfs met een simpele RBD al klaar bent...

RAM opslag zit ik ook naar de kijken inderdaad, beste oplossing en inderaad absoluut niet duur (in vergelijk met NVMe).

Ik weet niet alvast wat de uploads zijn, dit is random. kan ergen tussen 60 MB - 5 GB zijn (voor 95%, laaste 5% is groter).

Infinityband is inderdaad een optie, ook hoor ik veel over "Aspera" wat misschien ook interesant is, echter hangt dit af van het prijskaartje.

Hoe groter dit topic word, hoe duidelijker het is dat er meerdere servers nodig zijn, al is het voor redudancy. De uiteindelijke test setup zal het kleinst zijn en vanuit daar bouwen we het verder uit.

Rolfie schreef op maandag 01 augustus 2016 @ 17:48:
[...]


Opzich redelijk simpel.... Maar om het te beschrijven is een stuk lastiger. Een flow diagram of tekeningen zijn hierin een stuk gemakkelijker.

Maar dezelfde architectuur: Database, Controller, Worker.
De working is gewoon een script wat "iets" aftrapt. Er kunnen meerdere workers op 1 server draaien. Hoe is een tweede. Dit kan dus een FTP, RSYNC CURL SCP commando zijn.

De controller weet dat er bijvoorbeeld 10 workers zijn, verdeelt over 5 servers. Dus 2 " workers per server.

De controller zorg er dat een worker altijd 2 jobs actief heeft in de database als er een upload gedaan moet worden.

De eerst job op een server, moet checken of de benodigde source file aanwezig is, zo niet, kopieer deze van locatie X, en plaat deze op een RAM drive op de server voor optimale snelheid.

Hierna lees "een" worker uit de database zijn opdrachten uit.
job1: file X via FTP upload moet worden naar host: ftp.tweakers.nl met userid en password en de file moet op locatie Y neer gezet worden.
job2: file X via FTP upload moet worden naar host: ftp.tweakers.be met userid en password en de file moet op locatie Y neer gezet worden.

De worker gaat job 1 uitvoeren, en zal hierna het resultaat uploaden in de database. En de worker vraagt meteen een volgende job aan, welke hij meteen gaat uitvoeren.

Ondertussen ziet de controller ziet dat job 1 gedaan is, en zet meteen een nieuwe jobs gereed, zodat deze ook uitgevoerd kan worden. Mocht een worker hangen, dan zal deze geen nieuwe opdrachten te verwerken krijgen. Aangezien in de database nog steeds de jobs niet op completed staan.
Is een worker langer bezig, omdat bijvoorbeeld andere FTP server maar een 10Mb verbinding heeft, maakt niet uit. Hij verwerkt dan gewoon minder jobs. Vergeet niet dat jij misschien wel een 100Gb verbinding hebt, als de andere kant dit niet heeft, zal jij hier rekening mee moeten houden.

Je moet hierbij nog heel wat fout afhandelingen programmeren en monitoring. Maar deze architectuur is schaalbaar. Immers een worker is een bouwblok, die ergens staat. Of dit er 10 of 100 zijn, maakt niet uit.
En misschien kan je nog wel meer intelligentie bouwen in de database, maar heb ik nu niet voldoende kennis van. Of kun je dingen op een andere manier nog beter doen.

Misschien kan een worker wel meerdere jobs tegelijkertijd afhandelen, maar dit maakt fout afhandeling alleen maar complexer. Ik zou dan eerder gaan voor meerdere workers.

En vergeet niet dat, als jij hier een dienst van maakt voor je klanten, je redelijk moet nadenken over controles monitoring en schaalbaarheid.
Zomaar een script aftrappen, is altijd gedoemd tot mislukking, want er zal altijd ergens wel iets verkeerd gaat, waar je dus rekening mee moet houden.

Maar het gaat om het idee.....

Als je er eens over wilt brainstormen, stuur dan een DM.


.

Zelf heb ik momenteel de beste ervaringen met RSYNC omdat die het makkelijkst een script uit kan voeren en het minste poes-pas heeft.

Wat je schrijft makes-sense en is duidelijk, echter de XY voorbeelden geven een 1 -> 2 -> 3 (ookal verdeeld over workers) idee. dus na elkaar, klopt dit?

Wat ik als idee had (niet zeker of haalbaar is)

X -> Y1,Y2,Y3,Y4........Y24,Y25.

Allemaal tergelijk. Zodat die 100 gbps vol vermogen gebruikt word ipv zoals jij zegt dat enkele van de 25 lagere snelheid heeft op dat moment door wat voor reden dan ook.

Dus zegmaar X lokatie in de RAM komt een file. en desnoods runnen er 25 RSYNC clients met elk een eigen doel. Die automatisch starten, allemaal tergelijk. Of dit nou 1 of 5 servers zijn. 5 x 5 clients. Enige minpunt is dan de variatie van de 25 end-points. Als er 20 gbps per server beschikbaar terwijl het sneller kan of uiteraard andersom, dat er maar 5 of 10 gbps gebruikt word. Vandaar. Of uiteraard gewoon via de switch alle 5 toegang geven tot de hele 100.

[Bigs]

Weet je zeker dat je naar een elke individuele ontvanger meer dan 10Gbps kunt pompen? Lijkt me sterk.

Als je daar geen rekening mee hoeft te houden dan zou je kunnen kiezen voor drie servers met elk 4x10GbE (= 120GbE bandbreedtte). Dat is makkelijk vekrijgbaar, voordelig en bovendien heb je dan redundantie die je met een enkele server zou missen. Neem dan ook gelijk redundante L3 switches (wat dan tevens je routers zijn dus) en kies voor meerdere kleine poorten ipv een 100Gbps poort.

Maargoed het hangt nog steeds af van de requirements he Ik weet niet wat er precies mee gedaan wordt maar het klinkt mij allemaal nogal overdreven. Wordt de data ook aangeleverd via een 100Gbps verbinding? Of duurt het transport naar de deployserver 30 minuten en moet daarna elke seconde bespaard worden bij het uitrollen naar de CDN's?

[johnkeates]

Ik zie eigenlijk nog steeds niet welk probleem je nou probeert op te lossen. Heeft het toevallig iets met het crypted linkje in je profiel te maken?

[jvanhambelgium]

idd, wat zijn de requirements naar timing toe ? Binnen maximaal hoeveel "tijd" moet content downstream gerepliceerd worden. Wat is acceptabel ? Vanaf daar kan je ook beginnen inschatten naar boven toe wat de links zouden moeten worden minimaal etc.

Ik denk dat we hier wat aan het overdrijven zijn...N x 100GBps hebben wij ook liggen...maar dan wel tussen core-routers waar heuuuuul veuuul klanten door gaan...

[djluc]

Het ligt aan hoe je het bestand aangeleverd krijgt: De snelste manier is namelijk simpel:

De delen van het bestand die je binnen hebt meteen, live, doorleveren aan de 25 partijen. Als je wacht tot het bestand in z'n geheel binnen is verlies je tijd.

Dat doen we in de praktijk bijvoorbeeld met s3 van Amazon: http://docs.aws.amazon.co...S/S3.html#upload-property

Dus: Er komt een deeltje binnen op je deploy server, dat deeltje gaat naar Amazon, volgende deeltje etc.

Veel sneller kan het niet. Uiteraard kan je gewoon op 1 server meerdere processen runnen die hetzelfde proces doen. Voor FTP zie ik bijvoorbeeld hier een voorbeeldje van een stream upload: http://stackoverflow.com/...ble-stream-from-an-object

Als je server qua capaciteit vol zit kan je dit uiteraard ook op meerdere servers doen:

1 aanlevering -> naar 3 servers door streamen -> dan naar de 25 door streamen

Nog idealer wordt het als je de aanlevering gewoon meteen naar meerdere servers kan streamen uiteraard. Dat vermenigvuldigd sneller en is natuurijk wat meer failover.

Je noemde dat het 2 seconden duurt om van de 25 -> 800 POPs te deployen. Dat wil dus zeggen dat ze dus 32 POPs vanaf 1 POP. Als we even aannemen dat jouw proces van 1 aanlevering -> 25 POPs ook 2 seconden duurt, is dat wat je verwacht?

[Barreljan]

Volgens mij, maar ik kan het mis hebben, is er nog niet duidelijk hoe je nu wilt connecteren.

AMS-IX voor 80% peering en de rest Transit. Dus je moet hoe dan ook BGP gaan doen.
Een goede BGP router is dus nodig, of een dikke server met een Quagga BGP daemon erop (lijkt mij niet ). BGP policy configureren is niet zomaar een dingetje, ik hoop dat dit bekend is. Je kan het namelijk makkelijk verknoeien en dus niet alleen voor jezelf.

Maar dan nog, 100Gbit @ peak door een router, betekend al snel een serieus flink model en dus flink geld (je komt makkelijk de 100k voorbij incl interfaces en supportcontract) en nog maar niet te spreken over in chassis-redundancy. Goed, het is aan data max 1-2 gbyte dus je kan eventueel met minder, maar de 100Gbit interfacing is duur.

Kosten besparen of laag houden? Een ISP zoeken die 10-100Gbit mogelijkheden bied met een full cabinet colocatie, en je dus alleen een def. gateway hoeft in te stellen. Die jongens zijn daar voor en hebben al peering/transit (en transit tegen vast lagere mbit prijzen dan dat jij kan regelen). Welke transit leverancier had je op het oog? Het moet wel een stabiele partner zijn, dus Cogent valt al af ondanks ze goedkoop lijken.


Ik kan wel meer meedenken maar dan moet ik even wat meer informatie hebben

[ Voor 5% gewijzigd door Barreljan op 10-08-2016 11:47 ]

[Qwerty-273]

Klinkt wel in de oren als een concept in elkaar gezet door een project manager die de techniek wel weet, maar niet er volledig genoeg inzit op elk aspect.