Netwerkupgrade: nieuwe Fortinet-firewalls en switches van Arista

Het is alweer enige tijd geleden dat we over ons serverpark schreven. We hebben in de tussentijd echter niet stilgezeten. Zo zijn onder andere de webservers vervangen, is het videoplatform van een update en nieuwe servers voorzien en zijn de nosql- en search-databaseservers vervangen.

De laatste tijd zijn we echter vooral bezig geweest met het aanpakken van de infrastructuur in onze racks. We hebben de stroomvoorziening aangepast en een begin gemaakt om ons core-netwerk om te bouwen naar een hybride van 10Gbit en 1Gbit. Voor dat laatste hebben we nieuwe switches en firewalls geplaatst.

De oude situatie

Toen we ons rack inrichtten kozen we voor zogenaamde 'zero-U' verticale pdu's. Die pdu's waren links en rechts achter het rack geplaatst. Daarmee bespaarden we ruimte in de racks, maar ze zorgden ervoor dat we achter de racks erg weinig werkruimte hadden en ook kabels lastig weg konden werken. In de praktijk bleek dat we die ruimtebesparing in de racks niet nodig hadden. We hebben daarom per rack de twee zero-U pdu's vervangen door vier "standaard" 1U horizontale pdu's.

Op de eerste foto hieronder zie je met enige moeite de zero-U pdu's. Ook zie je een ongebruikte switch onderin, deze konden we niet verwijderen door het gebrek aan werk- en manouvreerruimte.

De oude en nieuwe pdu-situatie en de chaos die je krijgt als je elke server met 5x ethernet aansluit

Ook in het netwerk was verbetering mogelijk. De switches waren onderling allemaal met 10Gbit-links verbonden, maar ze hadden niet genoeg 10Gbit-poorten om ook de servers zo aan te sluiten. Voor meer dan 1Gbit bandbreedte moesten we losse 1Gbit-verbindingen via channel bonding laten samenwerken. Zoals je op de laatste foto kunt zien zorgt dat voor aardig wat netwerkkabels per server. Ook onze uplink naar True werkte op die manier; door twee keer twee 1Gbit-verbindingen redundant aan te sluiten konden we maximaal 4Gbit/s gebruiken.

Daarnaast was de beveiliging van ons netwerk niet optimaal. Bij gebrek aan een 'echte' firewall, maakten we gebruik van functionaliteit in onze loadbalancers. Voor de enkele server die direct aan het internet hing moesten we bovendien een eigen iptables-firewall inrichten. Het was niet netjes, maar met ipv4 werkte het nog best goed doordat nat de toegang tot het interne netwerk zo goed als onmogelijk maakt. Met ipv6 was die opzet niet praktisch en hadden we een extra reden om te zoeken naar wat anders.

Het nieuwe netwerk

Door de toenemende populariteit van onze video's zijn we af en toe tegen de 4Gbit-grens aangelopen. Een snellere verbinding stond dus op de wenslijst. Nog meer 1Gbit-aansluitingen bundelen vonden we niet erg handig, dus we hebben ervoor gekozen om over te stappen naar een redundante 10Gbit-verbinding. True, onze hostingsponsor, vond dit geen probleem. Helaas konden we met de bestaande opstelling niet overstappen omdat onze switches niet over genoeg 10Gbit-aansluitingen beschikten.

Met 10Gbit-uplinks willen we natuurlijk ook dat de loadbalancers en servers 10Gbit kunnen uitsturen, waardoor switches met meer dan vier 10Gbit-poorten - zoals in onze oude switches - ook hoog op de wenslijst kwamen. Verder wilden we de beveiliging nu goed regelen, wat firewalls met 10Gbit-capaciteit noodzakelijk maakte.

Op aanraden van onze leverancier Quanza hebben we twee Arista 7150S 24-poorts 10Gbit-switches aangeschaft. Deze switches combineren zeer goede performance met uitgebreide functionaliteit en flexibiliteit. We kunnen met deze switches het netwerk in onze hoofdlocatie redundant opzetten en we hebben bovendien voldoende poorten om in de toekomst ook de servers op 10Gbit aan te sluiten. Het netwerk in de uitwijklocatie blijft vooralsnog gewoon 1Gbit.

Het nieuwe netwerk

De nieuwe firewalls

Het vinden van passende firewalls was nog best lastig. Zo hadden maar weinig firewalls binnen ons budget 10Gbit-aansluitingen. Die firewalls konden bovendien niet allemaal de 10Gbit-aansluitingen daadwerkelijk filteren. Sommige kwamen - volgens hun specificaties - zelfs niet verder dan een throughput van 2Gbit/s.

Uiteindelijk kwamen we, ook via Quanza, bij cyber-securityleverancier Fortinet terecht. De Fortigat 800C heeft voor onze hoofdlocatie alles wat wij wilden: twee 10Gbit-netwerkpoorten - waarbij wij met behulp van mlag en vlan's beide poorten gelijktijdig kunnen gebruiken voor zowel inkomend als uitgaand verkeer - een lage latency van 6μs en een ruime throughput van 20Gbit/s.

De firewalls gebruiken een "Network Processor"-asic om hardwarematig de basis firewall-functionaliteit te verwerken, wat die lage latency oplevert en dat ook nog eens voorspelbaar houdt. Bovendien kunnen twee van die asics in een high-availability-modus samen het netwerk beschermen. En dat alles past ook nog in een compacte 1U-behuizing, waar sommige concurrenten dezelfde capaciteit in 4U of meer stoppen.

Fortinet bood ook een geschikte firewall voor de uitwijklocatie. Daar hebben we geen 10Gbit en geen uitgebreide redundatie in het netwerk, dus hier konden we met een eenvoudiger model toe. Maar het liefst zou die natuurlijk wel op dezelfde manier bediend moeten kunnen worden; we kwamen uit op de Fortinet 300D.

De nieuwe netwerklayout, een firewall in het rack en de ipv6 firewall policies

We hebben in de hoofdlocatie twee Fortinet 800C's als active/passive-paar draaien. Als een firewall uitvalt, dan neemt de andere het over. Verder zijn ze ingesteld in een transparante mode 'layer 2' waardoor al het tcp/ip-verkeer kan worden gefiltered, zonder dat we het verkeer specifiek naar de firewall moeten sturen. De firewall kan ook in een 'layer 3'-modus werken, waarbij hij als nat-gateway fungeert, maar dan zouden we allerlei configuratie moeten dupliceren - zoals port-forwards - op zowel de firewalls als de loadbalancers en op alle servers de default gateway moeten aanpassen.

De firewalls zijn ondertussen al geconfigureerd en laten alleen nog verkeer door naar de ingestelde adressen, waarbij we zowel aan ipv4 als ipv6 hebben gedacht. Overigens bieden de firewalls ook nog aardig wat geavanceerdere features die we op dit moment ook niet gebruiken. We maken bijvoorbeeld geen gebruik van ips, vpn, Application filtering, ssl/ssh-inspectie, web-filtering en antivirus-functies. Van ieder van die functies gaan we natuurlijk wel nader bekijken of ze zinvol voor ons zijn

En de oude servers staan in Vraag & Aanbod

Reacties (246)

[Tristan]

Ik vraag me af of het overstappen op AWS niet interessanter is voor jullie qua kosten?

[Kees]

Nee, andersom. Ik heb toevallig daar laatst nog naar gekeken. Alleen al onze databaseservers (die wij voor ~10k euro aanschaffen) zouden de kosten oplopen tot meer dan $25000 per jaar per databaseserver bij AWS. En wij hebben twee databaseservers. We zouden dus elk half jaar een nieuwe databaseserver kunnen kopen en dan nog geld (en performance) overhouden ook. Let wel dat AWS niet in nederland gehost is en de latency naar de website dus een stuk hoger gaat zijn.

Als het echt moet dan is dat wel te doen, maar het is wel veel duurder, bijschalen/afschalen levert niet heel erg veel op ('s nachts lopen er ook allerlei taken).

Tldr: Nee, AWS zou ons op jaarbasis 5-10x meer kosten dan wat we nu uitgeven

[dantalion]

Daarnaast wat is nou mooier dan zoon server hok in lopen en 4 tot 6 racks vol eigen opgezeten pracht en praal aanschouwen. Daar kan geen cloud tegen op wat mij betreft.

[Megamind]

Totdat de boel in de fik vliegt, een heel DC zonder stroom zit, het hardware mannetje onder de bus komt etc. Cloud hosting is voor veel bedrijven gewoon een veel beter oplossing dan zelf klooien met servers, racks, koeling etc.

[supersnathan94]

Het "hardware mannetje" is natuurlijk ook redundant uitgevoerd .

Ik gok dat het bij t.net iets anders in elkaar zit dan een gemiddeld bedrijf en dat het zelf klooien met servers ook binnen de job omschrijving valt.

[Megamind]

T.net is volgens mij nogsteeds een nieuws aggregator met een flinke community en geen Saas platform met 1000en klanten. In de zin dat ze makkelijk het kunnen uitbesteden zonder dat de community daar onder te lijden heeft.

[Mopperman]

t.net is opgericht door geeks voor geeks. Men is vanaf begin af aan zelf betrokken geweest bij de ontwikkeling van de soft en hardware zover ik weet. Dus de expertise zit er zeer zeker wel.

[supersnathan94]

Precies. Ik weet wel zeker dat deze mensen het daarom ook veel interessanter vinden dit in-house te doen. Het is én een kosten besparing (het geschetste kostenplaatje van uitbesteding is echt behoorlijk in verhouding met in house de boel regelen) én door dat het dus in-house kompleet ontwikkeld is, is het dus iets eigens. Ook kan ik me niet meer herinneren dat/of Tweakers ooit een grote storing heeft gehad met fikse downtime tot gevolg. Uitbesteding met als reden een hogere uptime is dus niet echt aan de orde. En om daarvoor dan 4x zo veel uit te geven is helemaal niet slim. De infra zoals die nu staat is goed. Hij bied voldoende ruimte voor uitbreiding en is tot op heden betrouwbaar. Ik zou liever zien dat ze dit budget steken in het ontwikkelen van de website. Profiel pagina's en de daarbij horende V&A pagina's zijn nog steeds niet geschikt voor mobiele telefoons.

Dat zijn verbeteringen die je dagelijks merkt terwijl 0,5% hogere uptime niet echt interessant is.

[Mopperman]

Dat uptime punt/dingetje dat je noemt is ook wel leuk -> http://tweakers.net/stats/?Action=Serverstats

Leef je uit

[Reactie gewijzigd door Mopperman op 22 juli 2024 18:56]

[supersnathan94]

Helaas zeggen die stats niet zo heel veel. Behalve dan dat tweakers iets van 1000 dagen geen powerloss heeft gehad en dat de power dus redelijk voor elkaar is. Een restart voor updates/onderhoud is ingeplant een daar heb je back-up servers voor draaien. Vandaar dat 100 dagen uptime weinig lijkt. Het kan best zijn dat wij tweakers dat niet eens door hebben gehad ten tijde van de werkzaamheden. Alle grafieken met requests per seconde geven een goed beeld van de drukte over tijd. Hiermee kan dus een goed update scenario worden gebouwd zodat de impact minimaal is.

Als alle servers een uptime zouden hebben van bijvoorbeeld 6 dagen dan is er dus een fikse storing geweest. Een komplete shutdown waarbij de back-up generatoren/UPS apparaten het niet trokken. Zelfs in die gevallen heeft tweakers een uitwijk locatie als ik het goed begrijp en kan het ook dan zo zijn dat we er geen last van hebben gehad.

Uptime is dus niet meetbaar op deze manier. Wel als tweakers stroingen bijhoud en goed documenteerd. De downtime van Rabo/ING/ABN is aan de hand van alle nieuwsartikelen dit jaar bijvoorbeeld vrij redelijk uit te rekenen. Bij tweakers is dat niet mogelijk aan de hand van deze statistieken en grafiekjes. Wel als de daadwerkelijke downtime gedocumenteerd wordt.

[klakkie.57th]

Blijkbaar heeft Kees het berekend en is het 5 tot 10keer duurder.
En blijkbaar wegen de kosten niet op tegen de voordelen.
Gewoon een correcte evaluatie ..

[Timoo.vanEsch]

Behalve voor sites als Tweakers.net, natuurlijk.
Dit is de core van de hardwarespecialisten.
Tom's Hardware ga je toch ook niet vragen om via de cloud te gaan?

De cloud is interessant voor business models die allerhande zaken verkopen en allerhande documenten verwerken, maar nul verstand hebben van hardware.

[supersnathan94]

Linus media group zou ook veel minder leuke spulletjes hebben om te laten zien. Die storage server met SSD's krijg je niet even in de cloud overigens. Daar komt een heel duur internet abonnement bij.

[LopendeVogel]

Tsja ligt eraan, we hebben het hier nog altijd over tweakers.net, tweakers.net die niet durft hun eigen server opstelling op te zetten en het maar uitbesteed, daar zit toch geen logica in?
Uiteindelijk gaat het natuurlijk om 1 ding hier: een goed werkende website. En ik vind dat deze al jaren lang heerlijk werkt.
Een downtime liggen niet veel wakker van lijkt mij, ook wanneer je in het achterhoofd hebt dat tweakers.net alles zelf onderhoud.

Voor alle andere sites kan ik het me begrijpen, maar niet een tech site als tweakers.net, hun dienen zelf te tweaken en te onderhouden. Althans zo zie ik het.

Ik lees dus ook veel liever een artikel dan dit dan dat er een artikel komt die als volgt gaat:
Beste tweakers, doordat wij geen tweakers meer zijn en geen zin hebben om te tweaken en onderhouden hebben we alles mbt de website uit handen gegeven aan een cloud bedrijf.
Nah, zou min of meer een schande zijn vind ik. Ik vind het dus ook redelijk vreemd itt veel andere (schijnbaar) dat er over cloud systemen gesproken wordt, op een site als tweakers.net nota bene haha.
Volgens mij is het ook meer om weer even te kunnen klagen, het is namelijk nooit goed voor sommige. Hadden ze cloud gepakt dan kreeg je weer een hele andere discussie (En onze privacy dan? En waarom een tweakers site hosten maar zelf niet tweaken? Hebben jullie er geen verstand van om alles maar uit handen te geven? etc etc), doen ze het netjes zelf beheren krijg je dit... De wonderen zijn de wereld nog niet uit schijnbaar.
Waarom denk ik dat het puur gaat om het klagen?? Omdat er al voor deze keuze gekozen is en ze echt niet op advies van de reacties alles zullen dumpen om maar op cloud over te gaan. Over cloud spreken is dus totaal niet relevant, en lokt meer negatieve reacties uit dan dat we ontopic bezig zijn.

[Reactie gewijzigd door LopendeVogel op 22 juli 2024 18:56]

[xxxneoxxx]

Tsjah.. Een eigen aangeschafte smartphone kan inderdaad stuk gaan met een sim only simkaart. Maar het wil niet zeggen dat dan maar het duurste gsm abo met duurste bijbehorende smartphone (welke netto uiteindelijk mogelijk een factor 6 zo duur is), een garantie is dat de smartphone daarbij niet alsnog stuk gaat, waardoor je alsnog onbereikbaar bent.
Ondanks dat de gsm-abo verkopers je willen laten geloven dat de kans van onbereikbaarheid zo klein is, dat deze verwaarloosbaar is..

[DigitalExorcist]

Je kunt ook zélf zorgen voor redundancy... ;-) ben je tenminste af van het risico dat je cloudprovider over de kop gaat.

Cloud is leuk, maar "not in my backyard". Als ik zie hoeveel notices van Microsoft me dagelijks om de oren vliegen met "reduced functionality" binnen alleen Office 365 al, vrees ik dat dat cloudgeneuzel niet lang stand zal houden.

Gisteren liep men ook steen en been te klagen over de performance (voor zover daar uberhaupt al sprake van is...) van MS Azure services. Nee, 10x liever een eigen private cloudomgeving bouwen dan uitbesteden aan een volstrekt onberekenbare derde partij.

[Anoniem: 135756]

Wel als het je eigen cloud is in de vorm van POD's. Gave dingen.

[capsoft]

Waarschijnlijk hetzelfde verhaal voor Azure? Of alleen naar AWS gekeken?
Overigens wel leuk; een kijkje in de keuken!

[bigbadbull]

AWS & Azure zijn enkel goed indien je
1. hoge uptime wilt no matter the cost.
2. kleine toepassingen met weinig gebruik
3. onbeperkte outscale mogelijkheden wilt hebben.

probleem met cloud is dat je effectief betaald voor verbruik en constante uptime.
Dus eens je verbruik een bepaalde grens overschreden heeft is eigen hosting altijd goedkoper.

[ACM]

Volgens mij heeft AWS dit jaar ook nog een paar serieuze outages gehad... dus zelfs qua uptime is het nog maar gokken of het wel hoger is dan wat wij halen.

[xleeuwx]

Buiten dat AWS misschien even betrouwbaar is als TRUE zit AWS niet in Nederland.

Per definitie komt al je data dan al uit Ierland (Dublin) of Duitsland (Frankfurt) terwijl je afzetgebied grotendeels Nederland is.

Bron:
https://aws.amazon.com/ab...-4943-aa55-1e4bd7d9ca2e-2

[supersnathan94]

Zelfs al zou je afzetgebied wel ierland zijn, zolang de applicatie- en webservers in nederland staan maakt het alsnog niets uit. Het maakt het zelfs alleen nog maar trager omdat het dan ook weer terug moet. Ik vind het geheel nu soms al een beetje aan de trage kant (buiten intranet pagina's die in ontwikkeling zijn is dit de enige site waar ik vaak kom dus dat is niet echt helemaal eerlijk) dus uitwijken naar ierland oid voor je databaseservers lijkt mij niet echt een strak plan mbt timings.

[madcow22]

Het scheelt zelfs al veel als je locale datacenter mysql server neemt in plaats van een andere locatie in nederland.

[InsanelyHack]

Een kerneigenschap van Cloud is "Rapid Elasticy". Als je een installbase hebt die alleen maar groeiende is dan is er eigenlijk geen sprake van snel veranderende vraag in resources en is een eigen omgeving (evt Private Cloud) altijd interessanter. Overigens kleven er ook allerlei nadelen aan het gebruik van die "Elasticy" zoals het te laat teruggeven van de resources waardoor je allerlei onvoorziene kosten kunt krijgen. De verrassingen achteraf zeg maar.

[Cergorach]

Bij Azure loop je ook tegen beperkingen aan van het aantal iops op je virtuele schijven. Je kan den wel meerdere schijven nemen en die stripen (aangezien alles virtueel is is dat geen significant hogere kans op failure), maar nog steeds zit je dan op een max aantal schijven die afhankelijk is van hoe groot je VM is. Ze zijn wel bezig met snellere oplossingen, maar dat was een paar maanden geleden nog geheel niet op orde. Ik denk dat je in Azure voor de benodigde performance wellicht meer geld kwijt bent dan de €25k/jaar/server (16 core, 112GB, SSD, SQL Enterprise = €63k/jaar/server, meer als je meer dan de standaard support op wil hebben).

Dergelijke cloud oplossingen kunnen heel voordelig zijn voor bedrijven, voornamelijk omdat dit een dure serverruimte en nog veel duurder personeel kan besparen, maar zeer zeker niet geschikt voor alle oplossingen.

[GrooV]

Ik weet niet hoe je gekeken hebt maar je moet dan juist gebruik maken van de scaling als je naar AWS/azure/whatever kijkt. Als je deze opstelling 1:1 in AWS hangt kan je duurder uit zijn ja. Maar je moet juist slim omgaan. Video encoden kan je met spot instanties doen, zoals bijv. Vimeo doet.

Toch raar dat veel grote sites en diensten in de cloud draaien maar dat het voor jullie te duur is. Netflix heeft bijv. alles in AWS zitten en dat video platform is een stuk groter.

Sowieso snap ik de keuze van jullie eigen video platform nog steeds niet (tenzij jullie heel graag een brakke player willen hebben) en ik vraag me ook af of het kwa copyright ook allemaal wel mag

[Tuxwielder]

Toch raar dat veel grote sites en diensten in de cloud draaien maar dat het voor jullie te duur is. Netflix heeft bijv. alles in AWS zitten en dat video platform is een stuk groter.

Dat komt waarschijnlijk ook omdat Netflix niet alleen de rekencapaciteit meeneemt in de business case, maar ook de netwerkcapaciteit van AWS. Als Netflix die zelf zou moeten kopen of inhuren, dan zou dat vast een aanzienlijke investering betekenen. Met AWS zitten ze "vanzelf" op alle continenten.

Daarnaast hebben ze vast een heel goede deal

[GrooV]

Mwah valt mee, als je een beetje internationale speler bent dan kom je makkelijk zat aan goede internationale routing. Daarnaast heeft Azure veel meer dc's dan AWS dus als die reden zou gelden zou iedereen op azure zitten (en ja azure heeft ook zeer goede *nix ondersteuning)

[army]

Veel access providers zetten gewoon lokale caches van Netflix in hun eigen datacenter net zoals dat voor andere videoplatformen wordt gedaan en ineens is de noodzaak voor veel netwerkcapaciteit weg. Een keer gaat een kopie naar de access provider en daarna blijft het lokaal verkeer. Voor veel access providers is het dus interessant om een lokale cache neer te zetten of je moet met meerdere 10Gb lijnen gaan peeren zoals vele nu doen met Google om YouTube verkeer een beetje te kunnen bijhouden.

[Powermage]

Netflix heeft eigenlijk alleen de basis in de cloud staan, alles wat bij de users afgespeeld word (de grote gigantisch bulk) komt voornamelijk uit eigen site's (opgebouwd uit all flash servers en HDD servers) en uit lokale caching machines bij ISP's.

[eborn]

Waarbij je natuurlijk wel moet meerekenen dat AWS (als het goed is) ervoor zorgt dat die bak niet zomaar down gaat vanwege een hardware/storage crash. Als je dat zelf wilt bewerkstelligen dan ben je sowieso 2 servers verder, inclusief de nodige configuratie.

Dan kom je in jullie geval nog steeds niet in de buurt qua kosten, maar voor de wat kleinere partijen kan dat nog interessant zijn. Mits je natuurlijk die redundantie nodig hebt.

[ACM]

Bij AWS moet je toch ook gewoon meerdere instances afnemen als je hoge uptimes wilt?

Ik neem tenminste aan dat bij bijvoorbeeld dit soort situaties, je anders nog steeds downtime hebt:
"Amazon RDS will automatically replace the compute instance powering your deployment in the event of a hardware failure."

Uiteraard is dat dan sneller dan bij je leverancier een nieuwe kopen en drie weken wachten... Maar het is alsnog niet geheel zonder downtime, lijkt me

Kortom, dan wil je Multi-AZ of 'Read Replicas' en daarbij moet je uiteraard gewoon betalen voor de server en storage.

Als je de bijbehorende kennis niet in huis hebt of er geen budget voor hebt ivt je omgeving, dan is het natuurlijk gelijk al een stuk interessanter

[Reactie gewijzigd door ACM op 22 juli 2024 18:56]

[bigbadbull]

klopt bij zowel AWS als Azure moet je verschillende instances afnemen en in HA groepen onder verdelen.
De verschillende instances staan dan best ook in verschillenden regio's (datacentra)
zodanig dat indien een DC een outage heeft je kan terugvallen op de backup DC.

en in tegenstelling tot je normale backup DC setup moeten deze gelijk zijn

[CrazyBernie]

Hoeft helemaal niet want azure en. Amazon ondersteunen allebei dynamisch traffic management dus op die manner kun je op basis van server status en geographies routeren tussen hele verschillende instances. Gaat er eentje in ierland down dan gaat het traffic naar een Ander dc.

Daarnaast vergeet iedereen inderdaad de kosten van piek. belasting en onderhoud. Onze klanten hebben bijna 500% meer traffic in het weekend dus wij latent automatisch schalen.

En aangezien wij bij zowel amazon als azure paas services afnemen hebben we helemaal niks te maken met installatie van tools.

Voor die besparing kunnen we per jaar zo ongeveer 80.000 euro besparen die een systeem beheerder kost die dit soort complexe omgevingen kan installeren en up to date Holden.

Voor dat geld kan ik enorm veel code die niet optimaal is maar wel werkt met brute kracht versnellen.

[klakkie.57th]

sorry maar 80.000 euro is voor een beetje bedrijf een lachertje natuurlijk als het om IT infrastructur gaat.

Cloud is perfect indien je het out-of-the-box gebruikt en geen vervelende vragen gaat stellen, maar goedkoper is het zeker haast nooit.

[ACM]

Ik gok dat de meeste bedrijven, iig specifieke onderdelen, maar wat graag een besparing van 80k realiseren als dat bovendien verder vooral voordelen heeft.

Zo'n lachtertje is het niet, dat hangt helemal van de context af; om het maar concreet te maken, ons moederbedrijf (de Persgroep) zou het inderdaad nauwelijks merken op haar jaarcijfers als er 80k meer of minder uitgegeven wordt. Maar het onderdeeltje Tweakers merkt dat wel degelijk. En dat geldt voor alle budgetverantwoordelijken die voor "kleine" bedragen (bijvoorbeeld 1M) verantwoordelijk zijn.

Sterker nog; ook als een groot bedrijf dergelijke besparingen laat liggen zijn ze gewoon niet handig bezig... Wat naturlijk niet zegt dat er nergens geld wordt verspild aan IT

[klakkie.57th]

Als je een FTE met ervaring 80K betaald gaat die in een outsourcingsverhaal ook 80K kosten indien die exclusief voor jullie werkt.

Indien we het dan toch hebben over besparingen , zou de vraag moeten zijn , waarom brengen jullie de tweakers IT infrastructuur niet onder in de algemene it infrastructuur van de groep zeker wanneer je een hardware refresh doet.

[CrazyBernie]

Inderdaad gaat hier om een rekenvoorbeeld.

[PcDealer]

Je neemt uiteraard wel support af met sla naar gelang hoe belangrijk de server is.

[Haykee]

Topspeed bellen heb je hem morgen!

[Tristan]

Ben je dan uit gegaan van EC2 instances die qua specs jullie fysieke hardware moeten matchen of heb je ook naar AWS RDS of AWS Aurora gekeken?

https://aws.amazon.com/rds/
https://aws.amazon.com/rds/aurora/

[Kees]

Een reserved instance db.r3.8xlarge komt redelijk overweg met onze specs (alleen onze specs zijn nog hoger). En daar betaal je dan $42,515 'up front 3 years' voor. Kwa pure hardwarekosten geven wij 'maar' ~10k euro uit per 3-4 jaar.

Dat zou overeenkomen met een db.r3.4xlarge. Maar vergelijk de performance van die instantie eens met een tweetal Xeon E5-2643 v3, 256G DDR4 geheugen, 4x 500G ssd's met raidcontroller /2G nv flash en 2x 10GBit/s SFP.

En aurora zou inderdaad mischien wel goedkoper kunnen zijn, maar daar zitten de kosten in 'i/o' en ik heb geen idee wat wij daar zouden doen (als je alles in geheugen laad heb je weinig leesacties op je storage bijvoorbeeld).

[Reactie gewijzigd door Kees op 22 juli 2024 18:56]

[aadje93]

je moet uiteraard rekenen dat "upfront" voor een EC2 instance wat anders is dan een server kopen, ik weet niet wat julle per maand kwijt zijn aan de racks, stroom etc (zal een stukje sponsoring van tru bijzitten ga ik vanuit) dat zit ook alleaal in de prijs inbegrepen, je kunt de instanes gewoon voor de volle 100% gebruiken zonder extra kosten (dataverkeer betaal je dan wel weer voor). Al ben ik het met je eens dat EC2 vooral voor kleinere toepassingen interessant is. Zelf draai ik een zeer kleine single vps (t2 micro) waar een paar websites met <50k pageviews per maand op draait. Met name videostreaming gaat bandbreedte kosten lijkt me. Alleen waarom niet de video's bij youtube "dumpen". Bespaart jullie een hele infrastructuur?

[Megamind]

Dat is leuk voor je web, maar het ging om de DB's, ik las gisteren nog een performance review waarbij RDS duidelijk stukken sneller was dan bare metal.

[ACM]

Heb je daar een link van?

[Megamind]

Was in de war met Redshift, dat is iets teveel van het goede voor Tweakers denk ik: https://www.periscope.io/amazon-redshift-guide

[ACM]

Ahja, als je een heel ander databaseparadigma gaat gebruiken, dan is het natuurlijk appels met peren vergelijken
Als ze nou RDS PostgreSQL vergeleken met 'bare metal' PostgreSQL, dan was het voor deze discussie wat relevanter geweest.

Ik gok dat als je iets als Cassandra, Hadoop of een van de modernere varianten met PostgreSQL gaat vergelijken, dat je dan ook wel allerlei queries kunt verzinnen waar ze significant beter scoren.

[sgrinovero]

Performance tests op AWS en RDS zijn niet te vertrouwen, het system can meer cachen als andere gebruikers minder zwaar bezig zijn.

Dat is vaak de reden om hogere performance dan een vergelijkbare "metal" server, maar eigenlijk gebruik je dan vaak een hogere spec machine in de praktijk. Je can beter opletten op minimal SLAs, maar die zijn erg lastig te benchmarken ;-)

[Calypso]

AWS (of Azure, of welke cloud dienst dan ook) is gewoon niet per definitie goedkoper. Echter ligt het eraan hoe je je businesscase maakt; elke case is namelijk in het voordeel uit te laten vallen voor zelf doen of voor cloud. Behalve bepaalde kosten wel of niet meenemen hangt het er vooral vanaf waar je je focus legt.

Zo is het voor sommige bedrijven erg interessant om geen voorinvestering in hardware te hoeven doen, en is dat een belangrijke reden om richting cloud te gaan, of het feit dat je een erg onvoorspelbare belasting van het park hebt en altijd een erg goede performance moet leveren.

Mijn ervaring met behoorlijk was usecases richting cloud is dat het voor 'normaal' gebruik (webservers e.d.) met 'normale' belastingspatronen meestal duurder is om richting cloud te gaan - behalve als je geen financiele mogelijkheid tot investering hebt, of zelf geen kennis hebt om op te bouwen/te onderhouden (en die dus in moet kopen).

[red123nax]

Het wordt vaak als uitwijk locatie of als opvang voor piekbelastig gebruikt. Ook wanneer mannetjes in het bedrijf moeten worden gehaald ben je met Azure of AWS niet op de juiste plek, dan heb je nog iemand nodig die verstand van zaken heeft. Dan kom je eerder terecht op een cloud omgeving van een IT Service provider terecht die alles voor je regelen.

[Torgo]

En de DR/uitwijk locatie? Ik zie nu een 1Gb capaciteit versus 10Gb in the main site. Geen optie geweest om de DR in the cloud te doen?

[red123nax]

Wellicht wel een optie als uitwijk locatie. Maar ik weet natuurlijk niet wat de uitwijk locatie allemaal doet en kan.

[M@rijn]

Klopt, je bent niet de enige die het uitgezocht heeft;

https://blog.serverdensit...ware-cloud-vs-colocation/

[Saven]

Aangezien je dan op personeel kan besparen denk ik dat het nog wel meevalt qua extra kosten.

[worrelborst]

Als ik het artikel lees, gaat het veel over netwerk uitbreiding. Hebben jullie al gekeken naar een Orbit van Edgeware?

[johnkeates]

AWS en consorten zijn duur, niet flexibel, ondoorzichtig en bieden eigenlijk alleen voordelen als je onbeperkt geld hebt of juist kort switcht op je aantallen. En je hebt natuurlijk mensen die niet weten hoe servers werken en behalve dat mediocre code op een host plempen nooit verder gekomen zijn daar is AWS en ook DigitalOcean goed voor.

[Tristan]

Ben ik niet met je eens. AWS is zo ingewikkeld als dat je het zelf maakt.

[johnkeates]

Ik zeg ook niet dat het ingewikkeld is, het is gewoon duur (TCO). De enige manier om goedkoper af te zijn bij AWS is om niks te gebruiken...

[Reactie gewijzigd door johnkeates op 22 juli 2024 18:56]

[Cergorach]

Wat een hoop mensen 'even vergeten' is dat je naast je directe hardware/licenties ook geld kwijt bent aan:
- Je eigen IT infrastructuur
- Huur ruimte en een goede server ruimte moet degelijk gekoeld zijn (wat ook niet goedkoop is)
- Stroom verbruik
- IT personeel/werkplek wat fysiek de server in de lucht houd en de IT infrastructuur (de serverbeheerder/database beheerder blijf je nodig houden), wat ook weer een stuk hoger is dan alleen een jaar salaris.

Vooral dat laatste punt willen de adviserende ITers nog wel eens spontaan 'vergeten' omdat het hun eigen hachje betreft.

Hardware in elkaar steken en de hardware werkend krijgen is echt niet het moeilijkste van de vergelijking, wat er op draait is het lastigst in mijn ervaring. Ik ben maar wat blij dat we al onze servertjes op een cloudplatform hebben draaien, klant wordt groter, mer resources nodig. 'S avonds even VM uit, extra resources toekennen, VM weer aan (desnoods schijven in WIndows uitbreiden) en de klant kan weer verder. En vanuit een financieel aspect is het voor menig MKBer qua financiën gewoon makkelijker omdat een clouddienst gewoon een terugkomende kosten post is die niet varieert en dergelijke hardware een investering is (die wellicht er voor zorgt dat je kleine investeringsregeling zo groot wordt dat je verder moeilijk kan afschrijven.

[Noeandee]

Je doet het voorkomen, alsof je alles in de cloud kunt draaien en je totaal geen IT kosten meer hebt op je lokale site. Maar dat is een sprookje.

Je bent zowiezo serveruimte kwijt voor switching, lokale servers tbv bijvoorbeeld printing en mogelijk nog een domain controllers voor je DHCP/DNS, etc. Daarnaast heb je ook nog IT personeel nodig voor je werkplekken, printers, etc. Ook een firewall blijft handig en mogelijk een VPN box en wat meer. En zo verder

In datacenters betaal je de volle mep voor ISO gecertificeerde ruimtes met alles erop en eraan, wat allemaal leuk in het kostenplaatje komt te zitten. En je moet ook verder kijken dan het financiële aspect. Er zijn ook nog allerlei secondaire aspecten, die het overwegen waard zijn.

Nee cloud oplossingen voor het MKB zijn echt niet goedkoper en flexibeler, enkele bijzondere gevallen uitgezonderd.

[Reactie gewijzigd door Noeandee op 22 juli 2024 18:56]

[Cergorach]

Je bent zowiezo serveruimte kwijt voor switching, lokale servers tbv bijvoorbeeld printing en mogelijk nog een domain controllers voor je DHCP/DNS, etc. Daarnaast heb je ook nog IT personeel nodig voor je werkplekken, printers, etc. Ook een firewall blijft handig en mogelijk een VPN box en wat meer. En zo verder

Daar heb je echt geen volledige serverruimte voor nodig die op het niveau gekoeld moet worden als een 16 core, 216GB server, met de batterij aan andere servers, storage, etc. Een lokale printing server, dc, dhcp/dns kan je prima kwijt op kleine passief gekoelde machines. Als je voor bepaalde oplossingen kiest hoef je zelfs geen dc meer te hebben.

Dan hebben we het niet eens over backup apparatuur, een server stuk, moet je toch al een backup klaar hebben staan. Dat hoeft niet bij een goede cloud oplossing, want als daar hardware stuk gaat word je VM verplaatst zonder extra kosten. En hoe ga je redundancy uitvoeren? (als je dat al wil en daar de kosten voor neer wil leggen). Dat ga je natuurlijk niet in dezelfde gemeente doen en zelfs in dezelfde provincie vind ik al risico vol.

Een cloud oplossing is flexibel omdat je het overal kan benaderen. Heb je geen internet of stroom op kantoor, mensen kunnen ergens anders verder werken. De downtime van bv. Azure is gemiddeld veel lager dan de downtime bij de doorsnee MKB organisatie.

We zien juist steeds meer MKB die grote delen van de IT niet meer zelf doen of lokaal hosten ivm. kosten, service en functionaliteit. Natuurlijk zijn er uitzonderingen. Het probleem is dat bij veel MKB de IT afdelingen zo klein zijn dat er slecht op kwaliteit kan worden gestuurd en dat redundency in personeel er niet is. Natuurlijk zijn er zat bedrijfjes die nog prima je lokale servers voor je bouwen en beheren, maar daarvan is de kwaliteit of erg wisselend of betaal je daar behoorlijk voor.

[klakkie.57th]

Maar indien jij wel support wil bij een cloud oplossing zul je er toch ook stevig moeten voor betalen en dan nog heb je meestal geen support voor de applicatie die jij gebruikt, laat staan zelf ontwikkeld hebt.

Outsourcen naar een cloud wordt gewoon oversimplified !!! alsof er plots geen kennis meer nodig is. Hardware setup/install en support is een bijna verwaarloosbaar onderdeel van de IT kostenpot. Om een goede redundante setup te bouwen van je applicatie in een cloud-omgeving is echt wat meer kennis nodig dan next-next-finish.

[aadje93]

bij AWS (en de cloud in het algemeen) kun je veel makkelijker schalen, dingen die met name overdag (of juist snachts) gebruikt worden kun je dus terugschalen in de rustiger periode. Autoatisch schalen is gewoon mogelijk (bij aws zelfs een complete wizard voor, zelfs een leek *ondergetekende* zonder enige diplomering in de ICT hoek kan makkelijk een schaalbare setup maken).

Uiteraard bijf je op je lokale site switching en eventuel vpn-machine(s) houden. Maar als ik mijn werk als voorbeeld neem, laboratorium. Zit een LIMS systeem achter (database server(s) plus enkele servers voor de koppeling van aparatuur -> lims). Overdag staan ze te zweten gezien er met 60-70 man non-stop (vanuit het lab) data in gestampt word. En op site door 100+ man data uitgelezen word. Snachts word er door maar 2-3 man data ingestampt en op site nog wel door ~30-40 man gelezen.

Je kunt dus een schaling maken die snachts op een kleine VM draait, en overdag enkele grote vm's erbij trekt. Scheelt toch op jaarbasis wat "loze" capaciteit die nu 's nachts vrijwel stil staat/stroom verbruikt/verjaard.

Het is niet zo dat het "ineens" goedkoper word met cloud, maar ik zie veel mogelijkheden omtrent schaalbare IT oplossingen die vroeger niet mogelijk waren. Uiteraard kun je ook lokaal met virtualisatie werken om te schalen (gewoon machines die fysiek afsluiten en met WOL gestart worden). Maar bij cloud kan dat stukken makkelijker. In ons lab gaat het 's nachts met hoogstens 1-2 requests per seconde als piekbelasting. Overdag kan dat zo een 100voud daarvan zijn door analyses met veel resultaten.

Snachts zou een pentium 4 machine het al af kunnen werken, waar overdag toch wat meer capaciteit nodig is. En de productie omgeving gaat het stadium "MKB" toch wel voorbij met ruim over de 80 medewerkers binnen het laboratorium, en een veelvoud aan "klanten". Die in het systeem hun resultaten lezen.

[Reactie gewijzigd door aadje93 op 22 juli 2024 18:56]

[blinchik]

Wij hebben eigen infrastructuur en hebben bij klanten stukken in de "cloud". We merken juist dat de cloud enorm veel beperkingen heeft. Met onze eigen setup hebben we een hele boel "reserve" resources, t.o.v. hetzelfde budget in de cloud, die we dus makkelijk zonder meerkost kunnen toekennen. Met de cloud worden die "meer resources", zelfs tijdelijk, een financieel gevecht met directie.

Snapshots, eigen backups managen, archivering is ook een verhaal dat heel moeilijk is. IAAS staat IMHO nog in de kinderschoenen en bij 3 grote cloudleveranciers (en "echt" grote) werd dit aan de klant beloofd, maar kunnen we dit totaal niet doen. Uiteraard kan de klant als kleinere KMO geen 24h contract betalen, dus na de uren kan dat niet, maar interne support ("de serverbeheerder") moet wel na de uren upgraden en kan geen snapshot nemen. Backups terugzetten is "on request", om over archivering (bandbreedtevereisten) nog maar te zwijgen.

Deze zaken durven verkopers nog wel eens spontaan 'vergeten' omdat het hun eigen loon betreft :-)

Vanuit financieel aspect is het misschien handig voor management, en het is misschien leuk als je 3 servertjes hebt, maar eens je deftige omgeving hebt, is een eigen omgeving (met eventueel een Cloud platform ala Azure voor testing / development) toch nog steeds een pak handiger en goedkoper.

Als IAAS volwassener wordt, en je daar ook nog eens VDI in zou kunnen draaien op een economisch verantwoorde manier, dan wordt het een misschien een ander verhaal.

[Cergorach]

Er zijn zeker situaties waarbij een eigen serverpark noodzakelijk is en in een aantal gevallen wellicht goedkoper all-in.

En bij een aantal grote leverancier in Nederland (die Azure Pack gebruikt) is het na kantoor issues onderhoud plegen op de VMs zelf een lastig karwei en soms zelfs onmogelijk omdat ze 'vergeten' zijn tijdens de sale duidelijk te maken dat ivm. backup ze rare dingen doen met de resources en je gewoon na 20:00 geen resources op een normale manier kan toevoegen. Dergelijke issues zijn er gelukkig niet bij MS Azure, heel veel kan je namelijk zelf, zowel via de portal als via powershell. En MS support zit zo een beetje in alle timezones. Maar MS Azure heeft natuurlijk weer andere issues (performance en lange support lijnen bv.). Er moet altijd geëvalueerd worden of dit verstandig is voor je organisatie en wat de beste oplossing is. Dat moet je natuurlijk niet laten doen door je eigen IT personeel of de externe verkoper, maar laat dat evalueren door een neutrale 3e partij (externe consultant die geen connectie heeft tot de andere twee parijen).

Hoe groter en specialistischer de organisatie, hoe groter de kans is dat zelf draaien uiteindelijk voordeliger is.

Waar we voorheen veel RDS inzette bij klanten zijn we nu bezig met VDI voor de MKB.

[aadje93]

draai anders bijzonder goedkoop een VPS in virginia (t2 micro) voor wat websites. Als jij me een goedkopere vps met burst mogelijkheden kan leveren die 1GB rammn bied hoor ik dat graag voor ~5-6 euro per maand. (1y 100% upfront). mijn website heeft ook in het afgelopen half jaar gewoon 100% uptime gehad vanuit AWS (zelf enkele reboots van de vps gedaan ivm testen/updates etc.) Het draait prima, en is ideaal voor kleine toepassingen. Database in RDS waar je geen omkijken naar hebt (goed kost ook ~5-6 euro per maand) maar de load word goed afgewend, en geoptimaliseerd

[synoniem]

Voor dat geld heb ik een simpele maar wel dedicated server in Frankrijk bij OVH draaien en dat werkt ook prima. Ok heb er wat moeite voor moeten doen om 'm te pakken te krijgen maar de volledige hardware voor je alleen hebben was me dat wel waard.

[aadje93]

Handig he, ff naar frankrijk want er is een hdd gecrasht

[synoniem]

Gelukkig huur je de hardware dus als het stuk gaat doe je een melding naar OVH en wordt het gerepareerd. Je moet zelf zorgen voor je backup uiteraard maar dat moet je bij een VPS ook.

[aadje93]

maar bijj dedicated heb je onvoorziene kosten (reparaties) die je bij een VPS niet hebt, je betaald gewoon een vast bedrag per maand, plus dataverkeer los (~9 cent/GB voor de eerste 10TB/maand daarboven in stappen goedkoper)

[Kees]

Ik heb bij dedicated nog nooit onverwachte kosten gehad voor vervangende hardware. Alle hardware koop je namelijk met een 3-4-5 jarig support waardoor dat soort verassingen tot het verleden behoren.

Bij dedicated betaal je meestal ook voor bandbreedte (en stroom, en rackspace) maar dat zijn losse contracen die je af kan sluiten en over kan onderhandelen, iets wat bij een vps meestal niet mogelijk is tenzij je echt heel erg groot bent.

[Powermage]

Dat ligt net aan de afspraken, kan best zijn dat alle hardware support er gewoon inzit en je daar geen variable kosten in hebt.

[Megamind]

Je hebt blijkbaar nog nooit AWS/Azure in een business case gebruikt. Wij hosten ook AWS omdat het veel makkelijker te beheren is, hebben toegang tot meerdere datacenters/locaties, kunnen VEEL goedkoper hosten dan zelf maar alles kopen en kunnen een paar man eruit gooien omdat we hun expertise op HW gebied niet meer nodig hebben.

[Powermage]

Ik vind dat altijd een lastige uitspraak.
wij draaien onze eigen omgeving waar wij onze klanten op hosten, en als ik kijk waar onze tijd als beheerders aan op gaat is 95% gewoon inhoudelijke server zaken voor de klanten (of ik dat nu zelf draai of bij azure of amazon maakt dus niet uit) de overige 5% is beheer van onze eigen omgeving (storages, switches, firewalls, hypervisors etc)

Waar ik vooral 'problemen' mee zie in de businesscase is de concurentie die je als SPLA partner met MS zelf aan moet.
Ik moet licenties duurder inkopen dan dat microsoft de oplossingen zelf levert (office 365) echter is het contract technisch gelimiteerd dat ik diezelfde bouwstenen voor mijn klanten inkoop.
Het speelveld op dat vlak word eigenlijk alleen maar oneerlijker dankzij MS.

[ACM]

Voor zover wij na kunnen gaan is het veel duurder. Maar dan gaan we wel uit van de list prices, wellicht dat daar op af te dingen valt.

En dan gaan we ook uit van de huidige hardware en alles 'aan'. Dat hoeft bij een cloudoplossing natuurlijk niet, maar met automatische schaling/inschakeling implementeren introduceer je natuurlijk allerlei nieuwe problemen die we nu nog niet hebben

Overigens wordt de 'primaire' locatie gesponsored door True, inclusief bandbreedte. Dat maakt de vergelijking nog wat makkelijker in het voordeel van onze huidige oplossing

[borft]

Ik denk dat het in jullie geval inderdaad niet uit kan. Bedenk wel het volgende:
- vanuit ierland/duitsland zijn de latencies best ok
- met reserved instances kan je makkelijk >40% besparen
- je hoeft alleen capaciteit aan te hebben die nodig is
- je bespaart ook op onderhoudskosten

Dat gezegd hebbende, vind ik eigenlijk dat een eigen hardwareoplossing wel past bij een community als tweakers.net

[Kees]

Onze capaciteit is alleen lastig naar beneden te schalen. Natuurlijk kunnen een aantal servers wel minder doen of uit staan 's nachts, maar er zal toch altijd een minimum moeten blijven draaien. Ook in de nacht doen wij onderhoud op databaseservers (met scripts) en willen we bereikbaar zijn voor onze bezoekers.

De minimale setup in AWS zetten zou nog steeds duurder zijn dan de hardware zelf aan te schaffen. Bovendoen moet jij ook het volgende bedenken:
- Bij downtime van aws kun je vaakl weinig anders doen dan met je duimen draaien
- Je krijgt te maken met onvoorspelbare performance, bijvoorbeeld storage of netwerk
- Je krijgt nooit dezelfde performance als een lokale baremetal server

De cloud kan zeker goed werken voor een heleboel toepassingen, alleen imo niet voor een site met een constante load/bezoekersaantallen. Maar als je bijvoorbeeld een website voor een tv-programma hebt dan is de cloud ideaal om een avond lang even wat extra capaciteit aan te zetten die daarna weer een week uit kan.

[Reactie gewijzigd door Kees op 22 juli 2024 18:56]

[Tristan]

Ik neem aan dat jullie bezoekers aantallen ook een golvend patroon weergeven. En dat jullie nu ruim meer capaciteit draaiende houden dan werkelijk nodig. Dus het elastic verhaal van AWS zou jullie voordelen kunnen geven, zeker zoals eerder aangekaart met reserverd instances. En s'nachts kan er flink terug geschaald worden voor de kleinere groep bezoekers.

Daarnaast doe je er inderdaad verstandig aan om vua verschillende regions redundancy in te bouwen, maar dat bevorderd niet de kosten.

[Kees]

Klopt, zie bijvoorbeeld http://tweakers.net/stats. Je zou op ongeveer 25% van de dag terug kunnen schalen. Dat is nog steeds niet erg veel. Bovendien kun je volgens mij niet dynamisch geheugen/cpu's schalen dus zul je iets moeten bedenken waardoor je ook echt dingen uit kan schakelen.

Verder draaien we in de nacht juist de backups en een groot aantal scripts waardoor we de databases bijvoorbeeld al niet meer uit zouden kunnen zetten, en die zullen we dan op moeten knippen waardoor je dus problemen gaat creeeren/oplossen die je nu niet hebt terwijl de site langzamer word en het waarschijnlijk meer gaat kosten

[Tristan]

Precies. De bezoekers lopen toch aardig terug snachts. Dus als je met een leger kleine instances werkt voor overdag kan je er daar snachts hordes van af schieten..

Voor de DB's denk ik dat je meer richting Aurora moeten denken ipv losse zelfbouw instances, zie Tristan in 'plan: Netwerkupgrade: nieuwe Fortinet-firewalls en switches van Arista'

[SampleUser]

Ik denk dat voor een grote site het beter is om de hardware zelf te beheren en niet afhankelijk te zijn van andere bedrijven...

[xleeuwx]

Tweakers is afhankelijk van True, True is afhankelijk van EU Networks

Je kan niet alles zelf in de hand hebben.

[Kees]

Daarom hebben wij een tweede locatie waar wij afhankelijk zijn van Atom86 en Telecity (en dus niet van True/EUnetworks).

Je kan wel veel in eigen hand hebben

[SampleUser]

Ik doelde eigenlijk op de server zelf, dus niet bijvoorbeeld datacentra.

[Kees]

Daarom hebben wij bijna elke server redundant uitgevoert zodat dat dus ook niet uitmaakt

[EricNL]

Ziet er gaaf uit! Alleen die "Goden" namen voor servers ben ik zelf niet zo van. Hebben zelf ook 1 zo'n klant, en loop me altijd helemaal rot te zoeken wat nou de domain controller of file server is.

[ACM]

Er zit nog wel een systeem in, hoewel niet per se helemaal duidelijk

De 'php'-servers beginnen bijvoorbeeld allemaal met een p, zoals phobos. En in de tweede locatie hebben we dierennamen ipv goden (en dan ook met een p, zoals panda).

En die eerste letter hebben we vaker zo gebruikt. Helaas heb je altijd kans op overlap bij dat soort dingen. De s van search of streaming vereist dan bijvoorbeeld enige creativiteit.

Maar wat vind je dan beter? Van die onuitsprekelijke 'logische' namen? Die je tijdens onderlinge communicatie steeds verkeerd doet? 'web01' is nog wel te doen, maar 'euweb01' of 'tcweb01' al minder. In ieder geval ivt phobos of panda.

En als je zo'n naam zonder het bijbehorende schema ziet, dan heb je alsnog geen flauw idee wat het nou precies betekent. Het grootste voordeel is dat het veel schaalbaarder is dan namen, want die zijn op een gegeven moment natuurlijk op

[EricNL]

Ja dat is ook weer zo. Ik persoonlijk vind "DC01", "NAS01" of "PS01" een stuk makkelijker, maar dat is natuurlijk puur gewenning. Ik geloof er ook wel in dat als je het systeem éénmaal kent, het wel wat makkelijker is, maar nogmaals: gewenning .

[Anoniem: 380117]

Je moet het ook zien als een stukje beveiliging. Als ik in jouw netwerk inbreek en ik zie dat ik op de DC01 zit, weet ik direct waar ik ben.

Zit ik op de server genaamd Zeus, wordt het al een stukje lastiger om verbanden te gaan leggen tussen de servers. Natuurlijk is het niet onmogelijk, en een beetje IT'er heeft het zo uitgevonden wat voor server het betreft.

Off-topic: vette profielfoto

[GrooV]

Obscurity is geen security...

[Kees]

Daarom zijn tanks ook altijd knaloranje geverft ipv camouflagegroen of een zandkleurtje want obscurity is geen security.

Security through obscurity is prima om erbij te hebben. Hoe minder een potetiele aanvaller weet des te lastiger is het voor hem. Maar het mag natuurlijk niet je enige security zijn net zoals een tank naast camouflage ook een pantser heeft

[Powermage]

Als iemand al zo ver is dat die in mijn netwerk(en) zit dan is die persoon ook vast wel kundig genoeg om alle rollen uit te vissen gok ik zomaar...

[xleeuwx]

tot dat je meer als 30 servers moet gaan beheren elke dag, en sommige server meerdere taken hebben en bijvoorbeeld 8 backup servers back-web01 krijg je dan.

Zo heb ik al alle muziek instrumenten voor bij zien komen en automerken server die weinig resources had was dan FAIT

[Reactie gewijzigd door xleeuwx op 22 juli 2024 18:56]

[trogdor]

Er was een bedrijf waar ze planten namen hadden.
Het duurde niet lang voor de ontwikkel en test server Cannabis heette :-)

[freshy98]

Zo'n type naam conventie gebruiken we hier ook.
<afkorting van het bedrijf>-prod/dr-<functie>01

Waar ik vroeg eens stage liep hadden de systeembeheerders ook leuke namen.
Daar was de hooflokatie ook niet blij mee, want die hadden totaal onduidelijk en saaie namen.
Maar zij hadden twee, en later drie, Novell servers. De Master heette Kwel, en de Slave (een breed type server) heette Billie.
Later kwam er nog een slave bij genaamd Guust (geloof ik).

[johnkeates]

Als je dat soort namen gebruikt is het net alsof je in 1990 zit en handig is het ook niet. Hoe noem je twee DC's waarvan 1 productie is en 1 acceptance? Ik ga zelf altijd voor een FQDN bestaande uit:

<functie>-<int>-<OTAP>.domein.tld

Dan zijn je hostnames altijd uniek binnen je netwerk en hoef je niet met subdomeinen te werken. Door de streepjes kan je dan lekker matchen met simpele regexes voor je orchestration en management. Bijvoorbeeld: pgsql-1-prod.example.com of ha-1-dev.domain.net om maar wat te noemen. Daar kan je natuurlijk ook shorthands voor gebruiken, maar dan ben je het overzicht ook weer snel kwijt. p1p.example.com is niet super duidelijk, en op die manier kan je maar 26 hosts kwijt als ze met een p beginnen...

[Ample Energy]

Als je je servers beschrijvende namen geeft is het voor een hacker vaak een stuk makkelijker navigeren en doelen identificeren. Als je op zoek bent naar een database-server en je komt alleen Odin, Thor en Loki tegen, dan heb je geen aanknopingspunt. Al is dit eigenlijk al een beetje achterhaalt, want vaak is een 'Mars' een mooier doelwit dan een 'Deimos' of 'Phobos'

Off-topic: Elke keer als ik dit soort dingen lees wil ik toch wel graag netwerkbeheerder worden

[Reactie gewijzigd door Ample Energy op 22 juli 2024 18:56]

[UPPERKEES]

Als een hacker al in je interne netwerk zit kan men met een nmap scan meer zien dan op basis van de hostname. Dus nee, dat maakt geen verschil in security.

[Anoniem: 677256]

Tuurlijk wel, als ik mijn webserver dc01 noem, de domain controller web01 en de fileserver db01 dan is een hacker al snel de draad kwijt Misschien wel een leuk ideetje voor een honeypot netwerkje.

Maar ff serieus, als je meer dan 10 servers moet beheren is hebben van "mooie namen" alleen maar onhandig. Zelf nummer ik gewoon alles en maak dan cnames aan per functionaliteit (web/file/db etc). Nummer komt ook gelijk overeen met het ip zodat je wat minder snel fouten maakt. Cnames zijn makkelijk aan te passen dus een verhuizing of vervanging wordt dan een stuk makkelijker.

[Blokker_1999]

Ik wil direct een potje UT gaan spelen op Phobos

[bigbadbull]

hoezo, dat zou toch de oppergoden moeten zijn;
Nuja wij hebben ook klanten die alles naar steden noemt, of ene klant die duidelijk fan is van "Charmed" : Prue, Phoebe, Piper, Page, Leo & Chris zijn de server namen. inderdaad zoek maar uit.

Langs de andere kant hebben we ook "logische" klanten waarbij de VMWS301 de DC is. "jach dat was de nieuwste server en de oude DC moest vervangen worden"

[sfranken]

Zo heeft ieder z'n eigen manier. Ik hanteer (Latijnse) namen van dieren/planten voor m'n servers, waar het doel de beginletter is (Webservers beginnen dus met een W, DB servers met een D enzovoorts)

[strompf]

Ik deed m'n afstudeerwerk aan de TU in Budapest in de jaren '90. Daar waren de servers genoemd naar de Zeven Dwergen (althans de eerste zeven).

Zelf noem ik m'n computers naar plaatsen op de https://en.wikipedia.org/wiki/Limes.

Een goede vriend van me was systeembeheerder bij Cisco. Hij noemde zijn computers thuis naar zijn favoriete pornosterren. Ik denk dat hij dat op z'n werk anders deed

[Blokker_1999]

Ach, bij mij zijn al mijn persoonlijke systemen vernoemd naar iets dat met Star Trek te maken heeft. Je documenteerd alles goed en dan komt het wel in orde.

En op het werk, aangezien ik in een afdeling elektronica werk, zijn alle servers vernoemd naar elektrische grootheden: Volta, Ampere, Ohm, Coulomb, Faraday, Hertz, Siemens, Tesla en Watt op dit moment.

Wat zou je trouwens doen met een server die meerdere functies bevat? domain-file-print-http.domain.tld ?

[johnkeates]

Wat zou je trouwens doen met een server die meerdere functies bevat? domain-file-print-http.domain.tld ?

Dat heb je eigenlijk alleen nog maar met hosts die niet gevirtualiseerd zijn of Windows draaien en daar door haast verplicht op een hoopje maar de services moeten uitdelen. Maar ook dan kan je ze een zinvolle naam geven. win12r2-1-prod.domain.tld bijv.

[alt-92]

Alsof er nooit linux-based slettebakken voorkomen die 5+ verschillende services bieden.

[johnkeates]

Natuurlijk zijn die er wel, maar bij Windows doe je het om dat het anders gewoon instant meer geld en onderhoud kost en de boel meteen overcompliceert. Bij Linux kan je gewoon kijken of je er zin in hebt en en doe je het wel of niet.

[alt-92]

Dat ligt niet aan het OS maar aan de knakkert die aan de console zit.

[goarilla]

Wat zou je trouwens doen met een server die meerdere functies bevat? domain-file-print-http.domain.tld ?

Deep Space Nine (DS9) ?

[Kees]

Ik kan mij dat goed voorstellen als je er niet vaak mee werkt. Persoonlijk vind ik het wel leuker om ze namen te geven.

De delen die co-beheert worden door mij en andere partijen hebben wel duidelijkere namen

[thegve]

Het maakt ook uit als je servers 'Pets' of 'Cattle' zijn, zoals een aantal beruchte blogs duidelijk maken ( http://www.theregister.co...vers_pets_or_cattle_cern/ ).
Bij een ex-werkgever begonnen met 3 man beheer, 2/3 servers intern en een paar honderd beheerd voor klanten met 'mooie namen' voor de interne servers, dat bedrijf groeide flink en met name de interne servers groeide uit toen enkele tientallen.
Die griekse goden gaan je dan de nek wel eens uithangen als er iemand aan komt lopen en die meld een storing op een anders betrouwbare webserver. Shit, hoe heet dat ding ook alweer..

[johnkeates]

Je gaat toch niet alle servers uit je hoofd leren? Servernamen zijn leuk, maar behalve dat het unieke hostnames moeten zijn zitten die gewoon in je classifier of CMDB en hang je overal gewoon de relaties aan...

[thegve]

Dat is een mooi ideaal, maar nog lang niet overal praktijk... In principe heb je wel gelijk. Bij die werkgever was dat niet zo, en bij 2 anderen (overnames..) ook niet.

[The Zep Man]

Ziet er gaaf uit! Alleen die "Goden" namen voor servers ben ik zelf niet zo van. Hebben zelf ook 1 zo'n klant, en loop me altijd helemaal rot te zoeken wat nou de domain controller of file server is.

Daarvoor is toch adequate documentatie beschikbaar?

[josipbroz]

Ik vraag mij af hoe verstandig het is om iets van je backend hardware online bekend te maken.
Interessant artikel, daar niet van. Dit soort info vind ik altijd iets voor binnen kantoor

[Anoniem: 265447]

Aan de andere kant; 'security through obscurity' is ook niet wenselijk

[armageddon_2k1]

Het feit dat je iets niet meld ergens wil nog niet zeggen dat er 'security through obscurity' toegepast wordt. Het is niet of het een of het ander. Dat impliceert namelijk dat Tweakers geen veiligheidsmaatregelen implementeerd omdat de leveranciers die ze gebruiken toch onbekend zijn.

[thegve]

Het impliceert dat helemaal niet. Het impliceert alleen dat ze dusdanig zeker van hun zaak zijn dat ze niet bang zijn om dit te vertellen/uit te leggen.
Als je bang bent om uit te leggen hoe je iets hebt gemaakt dan zit het waarschijnlijk niet goed in elkaar.

[Anoniem: 146626]

Het noemen van de bovenstaande merken/dienstverleners zal ongetwijfeld invloed hebben op de aanschafprijs van de hardware.

[SampleUser]

En een "kijk ons eens" factor

[josipbroz]

Ik stond er niet bij stil, maar volgens mij kan je wel gelijk hebben .
Online artikelen vergeet ik weleens vanuit een commercieel oogpunt te bekijken terwijl dat vaak een corebusiness(onderdeel) kan zijn.

[PcDealer]

Dat hoeft helemaal niet. Ik heb op mijn LI profiel veel merken en certificaten staan. Daar krijg ik geen cent voor

[t1mmy]

Er zullen ook geen honderden mensen jou profiel lezen...

[PcDealer]

Dat valt wel mee

562 weergaven van uw update

U heeft 1541 volgers

[Umbrah]

Ben je helemaal gek? Nooit Tweakers gekeken paar jaar geleden? Het feit hoe de site gegroeid is, waar het op gehost is, en wat het doet was altijd al een essentie. Sinds release tot zelfs nu is bekend geweest hoe de site ontwikkeld wordt, door wie hij ontwikkeld wordt, en waar hij op draait. Sterker nog: in de begin dagen werd Tweakers zwaar gesponsord juist hierdoor en omdat het een community enthusiasts was die dit gewoon interresant vond.

Dat laatste is niet veranderd, hoewel Tweakers wel wat commerciëler is geworden, maar de community, hoewel groter, is hetzelfde. Een kijkje achter de schermen is dan ook zwáár gewenst... niet alles hoeft nieuws te zijn. Het is al jammer dat we tegenwoordig ".Geek" nodig hebben (alles zou dat moeten zijn), maar het is al helemaal jammer dat dit soort dingen zó worden afgeblaft als "moet je dit nou bekend maken" en "is dit nou nieuws"? Dit is juist leuk, en past perfect binnen het begrip dat je security en DRM perfect kan hebben met open mechanismes en kennis.

[Miepermans]

Ik ben heel benieuwd naar de keuze voor Fortinet. De keuze voor Arista is geen rare keuze, echter zijn dit vrij top of market switches. Best prijzige units. Fortinet zit echter niet in het topsegment. Kan iemand dit toelichten ? Ik had hier eerder een SRX of Palo Alto verwacht.

[TAMW]

Prijs Fortinet Fortigate 800C singe unit € 10,000,-
Prijs Palo Alto PA5060 single unit € 130.000,-
Prijs Juniper SRX3400 single unit € 13.500,-
Prijzen zijn bij benadering en zonder de 10Gb sfp's

De top NGFW zijn:
Palo Alto en Checkpoint
Dan een tijdje niets dan komt Cisco en dan weer even niets en dan toch echt Fortinet.

Een Fortinet Fortigate is niet zo mature als de de bovenstaande merken,
maar om het als waardeloze Fisher Price firewalls te omschrijven zoals sommige hieronder doen dat klopt echt niet.

Als ze geen NGFW features gaan gebruiken was ik voor een Juniper gegaan in de tweakers situatie met een beperkt budget. Zeer mature maar geen echte NGFW.

Speelt geld een mindere rol zou ik voor een Palo Alto of Checkpoint gaan.

[Reactie gewijzigd door TAMW op 22 juli 2024 18:56]

[Stoute]

waarop baseer je dit? met een forinet kan je dingen doe die je met andere merken echt niet kan. simpel voorbeeld pingen vanuit een interface. echt zien wat er gebeurd met goede debugen kunnen andere merken echt niet.


Een Fortinet Fortigate is niet zo mature als de de bovenstaande merken,
maar om het als waardeloze Fisher Price firewalls te omschrijven zoals sommige hierboven doen dat klopt echt niet.

[TAMW]

Waarop baseer ik dit?

NGFW's implementaties/beheer horen bij mijn beroep. Deze rangorde komt uit de markt. Met alle merken uit mijn post heb ik veel hands on ervaring (meeste met Palo Alto en Juniper)


pingen vanuit een interface, is echt een heel normale basis feature, alle merken uit mijn post kunnen dit. Dit zit zelfs ook gewoon in standaard Linux

[Reactie gewijzigd door TAMW op 22 juli 2024 18:56]

[Stoute]

ik vindt het dan wel grappig moest laats met een palo alto een vpn maken vervolgens vraag ik of ze een test kunnen doen vanauit dat netwerk waarna we een vpn gemaakt hadden en dat was toch echt niet mogelijk van uit hen fortigate:

execute ping-option source 10.10.10.1

en daar gaan we dan

zelfde wilde redunctent vpn tunnel maken aan mij kant alles opgezet maar vanuit een palo alto was dat schijnbaar heel lastig en veel meer werk fortigate niet.

[TAMW]

Ik vind je post nogal onduidelijk.

Maar zo doe je een "Designate Source Interface for the Ping" op een Palo Alto.
Mischien was de palo alto engineer niet zo ervaren.
Een Palo Alto ipsec VPN instellen is als je het niet vaak doet idd even opletten. Als je eenmaal weet hoe je het doe is het ook binnen no time gebeurd.

Ik heb helemaal geen problem met een fortigate hoor, Bij een aantal projecten maken we de combinatie hoofdlocatie een PA en op de kleine remote locaties een Fortigate. Puur omdat de fortigate's daar prima voldoen en flink goedkoper zijn dan bv een PA200.

Palo Alto is wel m'n favoriet, maar ook een PA heeft bugs en rariteiten.
De prijs prestatie verhouding vind ook niet helemaal kloppen.

Enige uitzondering is de PA VM-100:
Goedkoop € 2800,-
En een echte 600MB throughput met alles security features aan. (AV/IPS/Url filtering)
De catch zit hem natuurlijk in het limiteren van het aantal rules/sessies enz.

[Reactie gewijzigd door TAMW op 22 juli 2024 18:56]

[Miepermans]

Dit kan Fortinet ook, je zoekt je alleen het schompes

Ik ben voor mijn werk voornamelijk met Palo Alto en Juniper bezig. Ik vroeg me echt af, waarom een partij als tweakers, gebacked door een groot mediabedrijf hier voor Fortinet koos. Wil je geen NGFW, ook goed ( en zoiezo in een datacenter een NGFW... dat is niet altijd de meest handige zet ) maar dan zou ik in toch voor Juniper gaan.

Goed om te horen dat de discussie hier wel op gang komt. Ik blijf hem volgen! thanks

[Kees]

We wilden niet perse een NGFW hebben, maar die fortinet's waren gewoon (relatief) goedkoop

We hebben zelf geen uitgebreide ervaringen met firewalls dus we werden niet gelimiteerd door iets als 'we willen palo alto want dat kennen we'. Onze leverancier heeft ons toen geadviseert om fortinet te nemen want daar hadden zij ervaring mee en dat voldeed volgens hen prima.

[Anoniem: 1322]

Zou je ook kunnen uitleggen waarom Palo Alto/CheckPoint zo "poulair" zijn? Is dat puur een marge kwestie? Ik zit niet echt in de firewall wereld maar de meeste die ik tegen kom zijn verschrikkelijk oubollig en bieden niet echt "next gen" functionaliteit. Ten minste als ik dat vergelijk met de Sophos UTM die ik thuis draai

[Sorki]

Ervaringen kunnen verschillen

Mijn persoonlijk rijtje is: Palo Alto > Fortinet > Checkpoint > Cisco

Volgens Gartner staat Fortinet staat aan de top in het UTM segment gevolgd door Checkpoint. Wat betreft de enterprice firewalls is het Checkpoint & Palo Alto die de kop trekken.

Checkpoint heeft imo de laatste jaren veel van zijn pluimen verloren. Ontelbare bugs, onvoorspelbaar gedrag en gewoon heel log als systeem. Qua management steken ze wél met kop en schouder boven iedereen uit.

Cisco heeft met de aquisitie van Sourcefire een stap in de goede richting gezet helaas zelf nog niet veel ervaring mee.

[TAMW]

Let op dat gartner de splising maakt tussen UTM(Small Bussines) en Enterprise FW's
Palo Alto zit niet in het UTM segment.

In het Enterprise segment zitten alle spelers hierboven genoemd.
Als ze dus allemaal wil vergelijken moet je bij de enterprise FW kijken

[Reactie gewijzigd door TAMW op 22 juli 2024 18:56]

[de echte flush]

Waar is (Netasq) stormshield in je lijstje ?

Zelf een POC gehad van verschillende firewalls (Enige waar we naderhand spijt van hadden is dat fortinet er niet bij zat):
- Sonicwall: Problemen met opzetten in onze config door technici, weinig moeite oplossing aan te reiken, was ook nog werk aan de firewall (functionaliteit)
- Palo alto: Na 3h was het POC model al dood (natuurlijk wel een nieuwe poging gehad). Al was deze firewall te duur zeker in vergelijking met andere firewalls (prijs/ functionaliteit).
- Checkpoint: mgmt-software crashte regelmatig (wat niet echt deftig overkomt bij een POC..). Wel deftige firewall, maar is het niet geworden door de interessanter geprijsde concurrent.
- Netasq (nu Stormshield): Veel moeite gebeurd door de technici om de firewall optimaal in onze omgeving te testen, goede support, snelle en veilige NGFW tegen een deftige prijs. (Het merk moet nog wat groeien, idd niet zo "mature" als bij onze vorige firewall (juniper) maar ze hebben wel al de goede mensen en instelling).

Stormshield is ook een Europees merk (altijd een leuke extra door met een goed product de eigen markt te steunen )

Hebben jullie nog andere merken bekeken (getest) ?

[Reactie gewijzigd door de echte flush op 22 juli 2024 18:56]

[MetalG]

budget?

[Fairy]

Super, zelf lang gewerkt met de Fortigate routers. Vind het heerlijke dingen om mee te werken.

We zijn hier echter (helaas) overgegaan naar Sophos. Ik vind die dingen onoverzichtelijk en eng. Sommige interfaces en rules kun je zonder bevestiging zo uitdrukken en dat soort gein.

[Steefph]

Wij zijn overgegaan van Cisco ASA naar FortiGate en dat was vanaf dag 1 drama. Weinig performance voor naar verhouding veel geld. Nu een Sophos erbij geplaatst en deze werkt toch een stuk vriendelijker met de grafische interface. True, het in en uitschakelen van rules gaat misschien iets te gemakkelijk maar, de rest werkt perfect.
De interface van de FortiGate voelt erg gedateerd aan (als je tenminste grafisch wilt werken )

[Reactie gewijzigd door Steefph op 22 juli 2024 18:56]

[Ajunne]

Precies wat ik wou zeggen. Die Forti-rommel werkt echt voor geen meter. Hier ook al ervaring mee, en je merkt echt dat het typische Fischer-Price my first firewalls zijn. Kan in de verste verte niet opboksen tegen een goeie Cisco of andere stevige apparatuur. Maar ik begreep dat er dan ook een budget was, dus dan wordt er al snel wat kort door de bocht gegaan... De pijn komt nog wel

[Kees]

Het heeft dan als voordeel dat mijn vorige firewal bestond uit 'iptables' op een de servers, dan is alles al snel beter. Ik ben so far nog niet tegen (hele grote) problemen gelopen. Het scheelt ook dat ons netwerk relatief simpel is (geen gebruikers in ons netwerk, alleen maar servers die ik beheer).

[Patrick_st]

Wellicht mis ik een heleboel kennis en inzicht maar wat is er dan mis met een firewall gebaseerd op IPTables en wat maakt "alles" al snel beter?

[Kees]

Nu hoef ik maar op 2 plekken de firewall te beheren en heb ik een punt waar al het verkeer langs komt.

Fouten in de rules vallen sneller op en bv een whitelist ip is eenvoudiger in te stellen

[goarilla]

Draaien jullie "ook" nog iptables op de servers, of heb je die gewoon openstaan nu ?

[stefklep]

Hier the same, wij draaien ook sinds een paar jaar Fortigate 300C voor ons netwerk als UTM en firewall. Het apparaat is inmiddels 3 keer vervangen, vaak het flash opslag geheugen wat stuk gaat. Een tip die ik zeker wil mee gegeven, als je het apparaat een keer een "harde" reset geeft/krijgt stroom af en weer op, doe altijd de check op flash memory waar die mee aankomt als je inlogt op de interface, duurt enkele minuten maar bespaart enorm veel ellende in de toekomst.

[Powermage]

Dat is zeker wel een gevoelig issue ja, zeker ind e 80C serie, bij 1 klant (redundante setup) zijn we nu bezig met exemplaar 7 en 8....

[ikke00]

Vanaf fortiOs 5.02 kan je als het goed is geen logging meer doen op local flash op alles onder een 100C, hoort ook gewoon niet te gebeuren want de storage in die toestellen is niet gemaakt om zoveel read/writes te incasseren.

[Powermage]

Storage in de 80C is gewoon uiterst brak.
Nummer 1 van die devices gaf tijdens de installatie al flash problemen (die ging al retour) Nummer 2 begon ongeveer 1 week later.
Nummer 3 en 4 begonnen toen een maand of 2 erna, die zijn toen in 1 klap vervangen en die hebben t eigenlijk een jaartje of 2 volgehouden.
Nummer 5 is gok ik een paar maanden geleden dood gegaan en nummer 6 overleed na een stroomstoring (bootte niet meer) echter ontdekte de klant toen pas dat nummer 1 stuk was.

[johnkeates]

Ik ben voor minder grote installaties gewoon naar pfSense gegaan, en voor UTM de boel uit elkaar getrokken en snort er naast gezet. Sure, je kan in theorie niet van UTM spreken als het niet in hetzelfde doosje zit, maar zo heb je maximale flexibiliteit voor een prijs waar ook klanten zonder Cisco-budget mee kunnen werken. Fortigate ook voornamelijk problemen mee gehad, Sophos was een tijdje leuk maar onder water is het niet veel anders dan een ander netwerk-OS en als je niet verslaafd raakt aan een specifieke GUI of CLI is het niet problematisch om over te stappen naar wat anders.

[GH45T]

Hier zowel via de webinterface als via SSH ervaring met FortiGate's. Weliswaar lichtere modellen maar dan nog, tot een paar jaar geleden werkte ik er regelmatig mee. Ik was er nooit zo van onder de indruk. Ook verschillende gekke bugs meegemaakt in die dingen en hardware welke kapot ging kwam ook nog wel eens voor.

Misschien is het tegenwoordig verbeterd maar ik zou alleen al door ervaring een Fortigate niet graag in willen zetten.

Lees net ook nog dat er dac kabels worden gebruikt. Ook daar heb ik inmiddels een hekel aan gekregen. Gekke problemen van wegvallende problemen bleken uiteindelijk in verschillende dac kabels te zitten.

[Reactie gewijzigd door GH45T op 22 juli 2024 18:56]

[Stoute]

zullen jullie wel iets verkeer gedaan hebben vanaf dag 1 niks meer dan verbeteringen
simpel voorbeeld de kleine unit voor de internetlijn die je hebt

[lordgandalf]

Mooi nieuw speelgoed. Schrik er wel van dat jullie al die jaren tot op nu achter een iptables firewall en een aantal loadbalancers hebben gedraait. Wat betreft ipv6 betekend dit nu ook dat ik met mijn ipv6 lijn jullie nu ook kan bezoeken ? Gaan de firewalls ook ant-ddos protection doen of gebruiken jullie daar standalone dozen voor ?

[Kees]

Nee, IPv6 staat nog niet in de dns voor de volledige website, maar het werkt wel voor een aantal testdomeinen. De firewall zelf is al wel klaar voor ipv6 en is ook al correct geconfigged ervoor.

En de firewalls houden inderdaad ook een heleboel ddos tegen (zoals de meeste reflectie aanvallen) maar tegen een gerichte ddos is vaak weinig te doen helaas.

[Fransfb]

Gewoon een vraagje uit interesse, is de RioRey er ook uit? ik kan mij nog ergens vaag herinneren dat tweakers destijds een RioRey had.

Even opgezocht:
reviews: RioRey RX1810: een firewall onder vuur

[Henk Poley]

Je kan vals spelen met /etc/hosts

2001:990:6:31::140 tweakers.net
2001:990:6:31::140 gathering.tweakers.net
2001:990:6:31::141 tweakimg.net
2001:990:6:31::141 ic.tweakimg.net
2001:990:6:31::142 twk.rs
2001:990:6:31::143 tweakblogs.net
2001:990:6:31::144 tweakers.mobi
2001:990:6:31:1ce:c01d:12c:1337 irc.tweakers.net

[Reactie gewijzigd door Henk Poley op 22 juli 2024 18:56]

[Kees]

Die werken niet meer geloof ik die ipv6 range rangeer ik uit

[Henk Poley]

Lijkt er op dat Safari's Happy Eyeballs dan ook in de DNS gegevens kijkt en naar IPv4 terugvalt.

[randomnumber]

2a00:1188:8:31::140 tweakers.net secure.tweakers.net gathering.tweakers.net
2a00:1188:8:31::141 tweakimg.net ic.tweakimg.net
2a00:1188:8:31::143 tweakblogs.net
2a00:1188:8:31::145 static.tweakers.net
2a00:1188:8:31::147 error.tweakers.net
2a00:1188:8:31::171 irc.tweakers.net

[Impuls]

interessante informatie omtrent de latency improvements op firewall niveau. 6µs / 20Gbit ...plannen om zelfstandige DC te worden ? :-)

[Anoniem: 1322]

Neem het allemaal niet te serieus met die mooie cijfers. Deze testen worden uitgevoerd met optimale packet grote en zeer basic functionaliteit (reken maar niet op L7 filtering). Uiteindelijk is de realiteit altijd zeer anders eenmaal in productie. Tijd zal het leren.

[ACM]

We hebben de 20Gbit al aangetikt in het productienetwerk en dat was geen 'ideale test'

Maar zelfs als jou voorspelling uitkomt, we hebben dit niet geplaatst om 20Gbit te hebben. We hebben het geplaatst om meer dan de voormalige 2x2Gbit te hebben en zijn daarbij uitgegaan van een redundante 10Gbit-lijn, alles wat ie door de redundante verbinding meer doet dan 10Gbit is mooi meegenomen

[ACM]

Neehoor, maar als je redundantie wilt moeten er minimaal 2 aansluitingen worden gebruikt... en als je 2x 2Gbit niet genoeg vindt, dan is het of nog meer kabels aansluiten of gelijk 2x 10Gbit

[brederodekater]

Waarom installeren jullie de netwerk apparatuur niet met de poorten naar de hot-isle gericht? Dat zou een hoop gehannes hebben gescheeld met kabels trekken van achter naar voren.

[ACM]

Dat zitten ze ook. De afdekking van de racks zit aan beide kanten
Hmm, ik moet vaker in ons rack kijken... goeie vraag inderdaad

[Reactie gewijzigd door ACM op 22 juli 2024 18:56]

[Kees]

Simpel: Omdat de bestelde apparatuur front-to-rear airflow had en het teveel gedoe was om dat weer om te ruilen. Verder vond ik het gehannes wel meevallen en nu is het ook mogelijk om het iets strakker weg te werken en aan de achterkan van je rack meer ruimte te hebben voor stroom/ethernet/kvm.

[SampleUser]

In welk datacenter staat dit?

[Kees]

EUnetworks en Telecity3, twee locaties.

[Noob_Saibot]

Is er ook bepaalde reden achter waarom er voor IBM hardware gekozen is?

[Kees]

Jazeker. Kosten.

We hebben op een gegeven moment bij de 3 serverleveranciers (IBM, Dell en HP) offertes opgevraagt waarbij IBM consistent 10-15% goedkoper was dan de rest.

Ja, dat verbaasde ons ook, dat hadden we niet verwacht, maar soms kan het nuttig zijn je vooroordelen opzij te zetten en gewoon de prijzen op te vragen

[hhoekstra]

Grappig. Bij ons komt IBM juist als duurste uit de test en zijn we over gegaan op Dell.

[The Reeferman]

Gaat dat over een vergelijkbare order of niet te vergelijken met deze?

[Kees]

Tot irritatie van onze leveranciers vragen wij vrijwel elke keer offertes op bij meerdere serverbouwers, tot nu toe komt lenovo/ibm meestal het beste uit de bus. En dat zijn vergelijkbare orders.

[PcDealer]

Dus grofweg de golfbeweging van allerlei->HP->Dell->IBM?

[Gillie]

Qua configuratie: Is het niet beter om objecten slim aan te maken?
Per server een object. En alle webserver objecten in een groep. Verder kan je ook een services groep aanmaken, HTTP en HTTPS samen brengen.
Voor alle webservers, één policy.
Of:
Bepaalde policies ook groeperen in secties (bv. per service/soort).

Verder kan je met FQDN objecten werken, maar nadeel. De firewall moet dan (extra) DNS queries gaan doen. Stel je verandert eens een IP adres. Hoef je niet gelijk firewalls te configureren. Maar ik verwacht dat jullie opzet redelijk stabiel is. Bij ons is het dynamisch.

[Kees]

Klopt, dat had ik eerst ook. In het begin had ik een adres-groep 'webservers' met als service-groep 'webservices' die 80/443 open zette. maar toen bedacht ik mij dat ik wel graag stats per server/poort wilde zien en heb ik de boel weer uitelkaar getrokken.

Als ik een ddos binnen zie komen dan wil ik graag weten wat er getarget word, dat is eenvoudiger te zien door per ip een policy te hebben en in sommige gevallen zelfs per poort en daar dan monitoring aan te hangen. Nu kan ik bijvoorbeeld het http vs https verkeer monitoren zonder de apache logs in te duiken.

[Gillie]

Is Netflow geen oplossing? Bijvoorbeeld om de Fortigate netflow output naar een Netflow analyzer server de streamen?

Met 'nfdump' zie je gelijk de top N sessions gesorteerd op source/destination IP/port nummers zonder Apache logs of andere logs door te spitten.

[Kees]

Ja, daar moet ik ook eens naar gaan kijken, dat is iets wat ik nu niet heb en dit was eenvoudig op te zetten met zabbix en snmp monitoring.

Netflow heb ik nog weinig mee gedaan dus dat moet ik eens een keer goed gaan uitzoeken.