The Gathering Technical blog

TG:Online Minecraft Server oppsett

19 Apr 2020, by from Event:CnA:Game

Hei igjen!

Dei fleste fekk vel med seg avlysinga av The Gathering 2020, som da opna eit prosjekt for å dempe TG-abstinensane frå både crew og deltakarar, nemleg TG:Online. TG:Online bestod då av litt konkurransar, mykje streaming, litt stemning på discord og ein tøff Minecraft server, som me skal fordjupe oss i her!

Det starta med at eg kom med eit forslag til den interne ide-gruppa til TG:Online den 17 mars, som lød slik:

Den stjerna skal eigentlig blinke gul og raud

Som da trigga ein del respons. Sjølv om forslaget mitt då var halvveis på kødd, viste det seg at samtlege crewmedlemmar var gira, og at Nextron, so gode som dei er, kunne stille opp med hardware til prosjektet. 12 dagar etter forslaget starta det første møtet der me drøfta korleis prosjektet skulle sjå ut, deretter hadde me to veker til det blei live, og slik blei det:

Hardware

Vi hadde alt ein bestilling på diverse serverar som blei bygd i forkant av avlysinga, som Nextron var gira på å låne vekk til TG:Online i staden for. Me fekk da 2(!) av desse specsa:

2x Intel Xeon Platinum 8280L – 28-Core 2.7Ghz Base 4Ghz Turbo
512GB RAM
2x 256GB M.2 SSD i RAID-1 (boot)
6x 480GB SATA SSD
2x10GbE SFP+

Det er gøy.

Men kor skal vi ha serveren? Vanligvis har me jo alle maskinene våre i vikingskipet, men ettersom den planen gjekk vestover måtte vi går til ein av KANDU sine samarbeidspartnere, nemleg colocation hos Nexthop!
Der har me og ein Fortigare brannmur som fort kan komme til nytte! Tidlegare har Ole Mathias posta bilete frå installasjonen av serverane

Software

I beskrivelsa av software til prosjektet snakkar me om alt av rein software som gjorde prosjektet mogleg, og startar kronologisk med det som er i botnen.

For i botnen starta me med Proxmox til kvar av serverane. Proxmox har blitt veldig populært inna TG sitt tech-miljø, og har opna for lett skalering, IPA, flytting av VM utan downtime med meir, so det var eit sjølvfølgje for oss!

Deretter kjem game sin favoritt, nemleg pterodactyl! Pterodactyl opnar da for veldig lett administering av docker containers av spel, deriblant forskjellige variantar av Minecraft serverar. Det har eit kult API, kjapp deployment muligheit for serverar, brukaradministrering av serverar, tilgang til filsystem og CLI til containerar, administrering av database og mykje meir!

Eksempel oppsett, her er alle “likesida” firkantane VM’ar, og dei avlange er Minecraft server instances i eigne docker containers

Deretter går me til det som er sjølve Minecraft serverane, og det har kanskje behov for ein liten forklaring.

“Vanleg” Minecraft køyrar java som dei fleste veit. Grunna det pluss Minecraft sin utvikling dei siste ti åra brukar Minecraft server instansen hovudsakleg kun ein CPU kjerne, som gjer da eit 56 core beist som me har litt ubrukeleg dersom me skulle berre hatt ein server instance. Difor gjor me som det fleire andre større serverar, nemleg å ha eit proxy oppsett. Det fungerar med at me har ein proxy, som bungeecord eller waterfall, som då i klienten sine auge ser ut som ein heilt vanleg Minecraft server. Om klienten prøvar å kople seg til proxyen, vil den då bli sendt til eit av serverane under proxyen. Proxyen lagar og ein bru for å kople seg mellom serverar, og kan bli konfigurert til å gjer mykje gøy!

Eksempel på proxy blokkdiagram, der waterfall er ein proxy server

Der har me valt å bruke waterfall som proxy server, som då er ein fork av bungeecord, og Tuinity som Minecraft server, som er ein fork av PaperMC, som er ein fork av Spigot. Phew. Me valgte da waterfall og tuinity rett og slett for at internettet sa dei skulle gi betre ytelse, noko som me tenkte me sårt trengte då CPU’en vår ikkje har like god single-core ytelse som dei fleste profesjonelle Minecraft serverar har. Med Tuinity arbeida me internt for å få best mogleg ytelse og optimalisering, og me var veldig bleeding edge med Tuinity verisjonen me køyrde i produksjon.

Litt anna som er verdt å nemne er at me konfigurerte ein close-to autodeploy av forskjellige Minecraft server instances, som gjer at dersom det hadde komt hundrevis, eller tusenvis av folk, kunne vi kjapt skalere opp anntalet survival, creative og lobby instances.

Plugins

Plugins på Minecraft er essensielle for å drive ein større server. Det kan ver plugins for å administrere moderering og banning på tvers av serverar, plugins for å stenge av spawn område, plugins for å lage portalar mellom server instances, osv osv. Naturligvis har me og behov for nokon plugins.

Plugins me brukte, der dei øverste er for server instances mens dei nedenfor er for proxy server

Me skal ikkje gå inn på alle plugins, ettersom der er mange småting som blei konfigurert. Men vi skal gå inn på det mest spennande!

LuckPerms er nok den viktigaste pluginen me hadde i sin heilheit, då det den gjorde var å passe på server rollar på tvers av instances. Dvs om man har moderator rolle på lobby, har man og moderator rolle på adventure server. Me hadde behov for ein felles database for den pluginen som alle serverane snakka til.

Ein anan plugin som krev database er CoreProtect, som loggar alt av aktivitet på kvar server, har rollback muligheit og mykje meir. Kontra LuckPerms krev den ein database per server, dog.

WorldGuard vart kun brukt på Minecraft Creative konkurranse server instancen, då der ikkje var behov for den andre plassar. WorldBorder blei brukt for å førehandsgenerere survival verdenane våre, som gjer me sparar mykje resursar på generering i produksjon.

Tall

Her kjem det som er gøy!

For vi rakk nemleg å bli ferdig med alt akkurat før tida, og hadde ein opplevelse som gjekk over forventningane når det kom til trøbbel!

Totalt var der 384 unike brukarar som besøkte serveren vår, med ein peak på 54 spelarar som var på serveren samstundes. TPS på alle instances var på 20 (det er perfekt) heile tida, utanom når folk lagde TPS-bombs med vilje. Men det blei kjapt rydda opp i.

Me hadde og ein testdag for å sjekke kor mykje ein server instance taklar med alle pluginsa me planla å bruke, på software oppsettet me tenkte å bruke. Då fekk me nær 50 brukarar som spelte samstundes, med ein TPS på 20, og CPU core load på 30%.

Anntal spelarar per tid

Eg vil gi ein stor takk til Christian Relling og Ole Mathias Aarseth Heggem for å bruke insane med innsats på å løyse plugins og det tekniske rundt prosjektet, og eg vil og takke alle byggarane, moderatorane, og støttespelarane rundt prosjektet som gjor at barn og unge fekk game litt samla i påska i år også <3

Link til alle kartene

Tech:Online, vinnere og oppsummering

15 Apr 2020, by from Tech

Da var Tech:Online avholdt. Det hele startet som en litt søkt idé, men vi fikk nærmere 30 påmeldte, cirka 20 fullførte. Vi fikk rett og slett ikke tid til alle!

Hele greia gikk ut på et enkelt konsept: Du som deltaker skulle konfigurere to deltakersvitsjer og en distroswitch så en simulert deltaker/klient kom seg på nett. Dette gjorde deltakerne (vanskelig å holde hvilke deltakere vi snakker om fra hverandre nå) på ekte hardware, ved hjelp av en raspberry pi som hadde 4 konsollkabler, en til hver av svitsjene involvert. Den simulerte deltakeren – la oss kalle det klienten – var en annen raspberry pi med statisk IP-addresse og en skjerm som lyste rødt for offline og grønt for online.

Det så cirka slik ut.

Tech:Online, med tre av fire stasjoner “i mål”.

I forkant av konkurransen holdt jeg to forskjellige stream sessions/foredrag/kall-det-hva-du-vil, med litt forskjellig fokus.

Alt i alt er jeg mektig imponert over hvor dyktig deltakerne var. Vi ble lovet tre billetter vi kunne dele ut, og det ble ikke lett. For det første måtte vi bruke mye skjønn: Det å sammenligne hvem som var raskest var veldig vanskelig, både fordi vi ikke egentlig hadde noen “stoppeklokke”, og fordi de som var først ut fikk en del forsinkelser som var utenfor deres kontroll. Med det sagt så lå fullføringstiden på mellom 1:30 (en time og tretti minutter) og 5:00. Jeg er mektig imponert over begge to: Selv om ting var godt dokumentert, var det flere mindre avvik fra dokumentasjonen, og uansett er dette ikke noe folk er vant til. Og det å holde ut i fem timer, og på toppen av alt be om en runde til etterpå for å se om man har lært, det fortjener ros.

Hvilket bringer oss til…

Vinnere!

Det er kåret tre vinnere, jeg går ut med “display navn” jeg, siden vi aldri formelt spurte om samtykke til noe mer (tid, og alt det der). De er:

- CafSneak
- ent3r
- Total_Ecl1ps3

De har alle tre vunnet hver sin billett til TG21! Delvis var dette basert på at de har utmerket seg, og delvis ble det trukket.

Alle som har deltatt og fullført har uansett grunn til å være fornøyd, godt jobba!

Bak kulissene

I skrivende stund slipper jeg koden som gjorde det mulig. Dette er rett og slett selve symbolet på det jeg vil kalle “hacking” i ordets opprinnelige forstand.

Du finner det på https://github.com/gathering/tech-online .

Det er MYE rariteter der, og det er ganske usminket. Les README.rst og “don’t try this at home”. Men et par ting vi har lært:

  • Vi burde hatt mer tid til å ettergå kabling og dokumentasjon før arrangementet. Dette visste vi egentlig i forkant, men tid er en begrenset ressurs.
  • Dokumentasjonen skulle vært RST hele tiden. Den ble konvertert til html i en one-off jobb, som gjorde at terskelen for quick-fixes ble for høy.
  • Det å jobb med en ekstrem tidsfrist er faktisk gøy! Da kan du ta snarveier du ellers ikke ville vurdert.
  • Vi skulle hat booking av tidsfrister og signup klar mye tidligere. Vi forutså rett og slett ikke at det ble så mange påmeldte, og vi visste ikke hvor lang tid folk kom til å bruke.
  • Bling betyr noe! Både det at nettsiden ble stylet fint og at det visuelle var litt pynta på var viktig.
  • Det blir en neste gang, men vi vet ikke når eller hvor eller hvordan!

Tech:Online?

19 Mar 2020, by from Tech

Da ble TG avlyst i disse COVID-19-tider. Nok er sagt om det, men mye var alt satt i bevegelse. Mange arbeidsdager er lagt ned i det.

Og vi (TG-crewet) prøver å stable på bena et alternativt arrangement i hurten og sturten, TG:Online. Hva dette vil være vet vi ikke helt enda, men det er uansett klart at Tech sin rolle vil være svært begrenset når vi ikke lenger skal levere nettverk og internett til 5000 mennesker.

Så jeg begynte å lure litt på hva vi kan gjøre?

En av tankene jeg har hatt er at vi har en masse nettverksutstyr vi ikke får brukt til noe. Jeg hadde selv behov for å labbe, så tok med meg litt stash hjem og så hva jeg fikk til.

Stue-lab, med “kant”, “distro” og “core”.

Så jeg leker litt med tanken på om vi klarer å levere noe sånt for flere? Vi har jo et tredvetalls konsoll-kabler og masse skjermer og NUCer på lager.

Man kan labbe virtuelt, men det har bare ikke den samme “feelingen” som fysisk utstyr har.

Hva om vi setter opp noe ala riggen på bildet, smeller konsoll-kabler på alt og lager en slags “capture the flag”-konkurranse der folk får mulighet til å konfe utstyret så pc’er kommer på nett? For å gjøre det litt gøy smeller vi på noe skjermer som “pinger” internett og litt sånt, med et webcam man kan følge med på? Gudene vet, men det høres gøy ut å prøve.

Aner ikke om det lar seg gjøre, men i mellomtiden labber jeg videre. Bli gjerne med i diskusjonen på TG sin Discord (#tech-kanalen) om dette er interessant!

The Gathering’s driftsløsninger

06 Mar 2020, by from KANDU:Systemstøtte

Hvordan drifter vi egentlig gathering.org, Wannabe og alle de andre tjenestene som TG bruker?

Tenkte å blogge litt om hva vi i KANDU:Systemstøtte har drevet med den siste tiden.

Systemstøtte er i dag både en del av KANDU og et TG crew. Skillet her er for tiden litt uklart. Men det gir jo mening at de som utvikler og drifter crew systemet til TG, starter litt før de fleste andre, og tjenester som Jira trenger kjærlighet med (u)jevne mellomrom. Det innlegget her skal ikke handle om strukturen i arbeidsgruppa, men greit å være klar over at det gjøres mye også utenom The Gathering.

Vi har en stund jobbet med å fornye avtalene rundt hosting av servere, og fikk rett etter nyttår i havn en avtale med Nexthop AS for colocation. Spesifikt 20 rack units i et topp moderne datasenter i nærheten av Oslo.
For en organisasjon med frivillige gjør tilgang 24 timer i døgnet ting mye lettere.

Colocation?

Colocation eller colo som det ofte kalles, er kort fortalt tilgang på datahall til å plassere servere og/eller nettverksutstyr. Leverandøren av datasenteret tar for seg drift av strøm, kjøling og annen infrastruktur. Vi fått tilgang på et «halv-rack» (20U).

1U er 4,44 cm i høyden, og standard 19 inch rack er på 48,2 cm i bredden. En vanlig server er fra 1U til 4U, spesielt om du har mye disker kan den være enda større. Les mer om colocation på nexthop.no

Nettverk

Vi har også jobbet med vår partner Fortinet for å bygge en nettverksløsning til å bruke i det nye racket. Sammen med Fortinet har vi kommet frem til en løsning som vi er veldig fornøyd med.

(Med andre ord, det bør holde en stund fremover)

Under konfigurering av utstyret

Internett er levert av Nexthop over 2 redudante gigabit linker. Vi har fått et /26 nettverk med IPv4 og en /48 med IPv6. Vi kommer også tilbake med en ny bloggpost når vi hatt litt mer tid med utstyret.

Servere

Via samarbeidsavtalen vi har med Nextron på The Gathering, har vi gjennom årene fått litt servere. Målet er å flytte alt over til racket vi har hos Nexthop og vi er allerede godt i gang. Basefarm har også hjulpet oss med servere, litt utstyr og møtelokale.

Vi har mange spennende planer for driftsmiljøet fremover, og detaljene der vil helt garantert komme i en ny bloggpost etterhvert. Per nå er miljøet hos Nexthop tenkt til alt fra produksjonsmiljøer med Gathering.org og Wannabe til testing av nye løsninger og for å mette behov for hosting som crewet har før og etter selve arrangementet.

Merk at vi fremdeles kommer til å ha servere i skipet under The Gathering, dette er bare for tjenester som må kjøre utenfor TG.

Edit: TG20:Online

Utstyr på vei…

05 Mar 2020, by from Tech:Net

Fikk akkurat mail fra Juniper-kontakten vår om at ting er pakket og klart. Forventet levering om et par uker.

I år blir det 4 kolli, av 596kg.

Kos. Akkurat nok til å ta i sekken.

En av fire kolli, pakket og klart.

Påsken nærmer seg!

01 Apr 2019, by from Tech:Net

Oppdatering fra Tech om The Gathering 2019 designet

The Gathering 2019 rykker stadig nærmere, og det er på tide at Tech:Net skriver kort om årets nettverks design og hvilket utstyr vi skal bruke. Det blir ikke veldig spennende for dere som leste om fjoråret, da vi utstyrsmessig, stort sett kommer til å gjøre nøyaktig det samme i år som i fjor, men les gjerne igjennom for å friske opp minnene dine!

TG19 i korte trekk:
– Det blir Juniper switcher og rutere i kjerne og til deltagere.
– Det blir Fortinet brannmur og wifi.
– Det blir Telenor for Internett.
– Det blir Nextron for servere.

TG-19-design

Kjernenett

Helt siden TG15 har kjernenettet (backbonet) vært basert på 2x 40 Gbit Ethernet. Utstyr, og plasseringen av dette har vært litt ulik fra år til år, men i år blir det likt som i fjor.

Kjerneringen vår blir bestående av tre rutere:
– r1.tele (2x QFX5100 i VC): Grenseruter mot Telenor og aksess for infrastruktur servere. Står plassert i telematikkrommet i Vikingskipet hvor fiber kommer inn.
– r1.stand (4x QFX5100 i VC): Ruter for game-, event- og infrastruktur -servere samt wireless kontroller. Står (på utstilling) i Tech:Net sin stand i sponsorgata.
– r1.noc (1x MX480): Ruter for alle deltagere. Står plassert ved glassburet hvor NOC sitter.

Core og distribusjon til deltagere

I år, som i fjor blir det en sammenfallet kjerne (collapsed core) bestående av en Juniper MX480 og 9 distribusjonsswitcher med 3x Juniper EX3300 satt opp i vritual-chassis. MX480en blir plasser ved NOCen, og fra den har vi 2x 10 Gbit Ethernet på hvert sitt fiberpar ned til alle distro switchene på gulvet.

MX480en har vlanene for samtlige bordswitcher og gjør videresending av DHCP pakkene til DHCP serverene våre.

Vi har valgt å gå for denne modellen da vi over tid har lært at Juniper sine EX3300 switcher ikke er kraftige nok til å håndtere lag3 og DHCP videresending med de kravene vi stiller. Det har vært fler tilfeller i tidligere år hvor vi har opplevd problemer med disse switchene. MX480en har mye kraftigere hardware, og takler nettverk som er mye større enn hva vi produserer på TG. Vi kunne klart oss med lillebroren MX240, men disse har Juniper lite av på demolager, så er lettere å få tak i MX480er.

Aksess

Som tidligere år vil aksess til deltagere (og crew) gjøres via Juniper EX2200 switcher med 48 porter. På alle deltakerbordene blir disse levert med 3x 1 Gbit Ethernet. På disse switchene kjører diverse first-hop-secuirty policier slik at vi kan forhindre angrep på infrastrukturen vår, og forhindre nedetid for andre deltagere ved feil som oppstår grunnet feilkofingurasjon hos brukerene. Eksempelvis så forhindrer vi at deltagere kan kjøre egen DHCP server og skape uregelmessigheter i nettverket.

Leveranser til crew og misc støttefunksjoner under TG

Tradisjonelt har dette blitt gjennomført ved å utplassere enkeltstående rutere rundt om kring i kriker og kroker i Vikingskipet som kjørte OSFP ruting. Nytt av TG17 var at alle disse ruterne ble en logisk enhet ved bruk av en teknologi kalt Virutal Chassis. Da oppfører alle boksene seg som om de er en, men har mange linjekort. Det gjør at vi kun trenger å forholde oss til konfigurasjon på et sted.

Nytt av årets TG blir at vi utvider denne logiske boksen med et ekstra “linjekort” da vi på TG i fjor opplevde å gå tom for porter på det linjekortet som står plassert ved NOCen.

Denne ringen vil i år bestå av 2x EX4600 (24p), 4x EX4300 (24p) og det nye ekstra linjekoret EX4300 (48p). De to EX4600ene blir satt opp som master og backup routing engine da har litt kraftigere CPUer enn EX4300ene og følgelig håndterer bedre hendelser, og trafikk som trenger prosseseringskraft. Eksempelvis videresending av DHCP pakker, eller håndtering av brudd på forbindelser mellom switchene.
Denne boksen (ringen) blir satt opp med 1x 40 Gbit Ethernet mellom hvert linjekort.

På linjekortene i ringen kobler vi opp tilsvarende distrubisjonsswitcher som brukes på gulvet (EX3300). Disse fungerer som distribusjonswitcher til støttecrewene som kobler seg til i EX2200er som plasseres i nærheten av crewene.

Vi mottok utstyret vi låner fra Juniper forrige uke, og helgen som var møttes en gjeng fra Tech:Net i Oslo for å pakke ut. Noen nøkkelenheter ble oppgradert til Junos 18.1 (mer om hvorfor kommer nok i en egen post senere!), og fikk basic config.

EXene og QFXene vi låner kom i denne fine kassen:
VanVault

Og her har vi ringen, klargjort med basic config og stående i VC. Klar for å spres ut i skipet. Hvis noen lurer, EX4300ene til høyre i bildet har sine 40 Gbit Ethernet porter i baken!
Ringen

For å kunne spre boksen r1.ring utover hele vikingskipet er vi avhenig av god fiberinfrastrutkur i skipet. Det ble lagt ned en enorm insatts i dette for noen år siden, og hvis du ønsker å lese om det og se bilder kan du se her:

TG og KANDU Open Sourcer wannabe og gathering.org-koden!

01 Apr 2019, by from KANDU:Systemstøtte

Over en årrekke har Wannabe, “crew-systemet” til The Gathering, utviklet seg til å bli et ganske sindig system for å ta i mot søknader til crew, generere dataunderlag til ID-kort, holde oversikt over hvem som skal rydde når, matallergier, og en hel skog av andre funksjoner som brukes for å avvikle The Gathering hvert eneste år.

Og i nesten like mange år har folk ønsket å bruke Wannabe til andre arrangementer enn TG. Dette er noe vi har lyttet til og i en lengre tid har det vært planlagt å slippe Wannabe som Open Source slik at du selv kan ta det i bruk – og bidra tilbake.

Hovedgrunnen til at det ikke har skjedd er den vanlige: Det krever at vi går litt over koden og sjekker at det ikke er noe åpenbart idiotisk der på sikkerhetsfronten, og så må vi faktisk gjøre litt praktisk planlegging av hvordan ting skal organiseres. Ikke mye, men litt.

I hvert fall siden jeg arvet “hovedansvaret” for wannabe i slutten av 2016, og Core:Systems ble “Rebootet”, har det ligget i kortene at Wannabe sin kildekode skulle slippes.

Så hvor er den?

Vel, teknisk sett ligger den på github, men fordi det er TG om et par uker har vi bestemt oss for at den rette tiden å slippe koden ikke er akkurat nå, siden eventuelle “katastrofalt dumme bugs” vil få så store konsekvenser. Derfor annonserer vi heller at koden vil bli sluppet offentlig litt etter TG, og den datoen er satt og godkjent som: 1. Juni 2019.

I samme slengen vil vi også legge ved koden som ligger bak gathering.org, da det ikke er noen grunn til at dette skal være lukket.

Så nå har dere noe å se fram til!

Om dere har noen spørsmål, ta gjerne kontakt på discord! (å finne discord’en vår er overlatt til leseren som en ferdighetsprøve).

Intro: Webservere og slikt

16 Mar 2019, by from KANDU:Systemstøtte

Om du fulgte med veldig nøye på ettermiddagen søndag 3. mars så la du kanskje merke til at www.gathering.org var utilgjengelig i en liten stund. Perioden med nedetid var varslet i god tid i forveien (ca 30 minutter) slik at alle i crewet visste hva som foregikk (her kommer altså forklaringen så alle i crewet vet hva vi gjorde).

Historien begynner med at noen små og store nerder satt samlet på Frivillighetshuset i Kolstadgata 1 i Oslo. KANDU:Systemstøtte hadde hatt møte dagen før og vi hadde blitt enige om at vi måtte gjøre noe med hvordan www.gathering.org fungerte. Før vi begynte bestod nettsiden av en server med en salig blanding av Apache, Varnish, WordPress, og vår egenutviklede Node.JS baserte web API. Konfigurasjonen var så komplisert at var lett å gjøre feil som kunne være vanskelige å nøste opp i. Vi bestemte oss derfor å bygge alt opp på nytt igjen. Dette er forklaringen på hva vi endte opp med, og en intro til hvordan det fungerer.

HTTP og HTTPS

Når du åpner en nettside med alle moderne nettlesere så benytter du en protokoll som heter Hypertext Transfer Protocol (eller bare HTTP). Protokollen håndterer å hente og sende informasjon til nettsider på en standardisert måte. Du har sikkert lagt merke til at foran de fleste linker så står det noe lignende http://example.com. Dette er en instruks for nettleseren om å prøve å nå example.com over http protokollen.

Det eneste problemet med protokollen er at alt du sender over den er fullt leselig for alle som lytter. Noen glupe hoder fant ut at om du legger til en S på slutten av HTTP så får du HTTPS, og “S”en står for “Secure”. Når nettleseren prøver å nå serveren så blir de enige om en felles krypteringsnøkkel slik at de kan kommunisere med hverandre uten at andre kan se hva som blir sendt. Metoden heter Diffie-Hellman key exchange (DH) og du kan lese mer om den her.

Før vi bygget om stacken vår så var det Apache som hadde ansvaret for å ta imot HTTPS tilkoplinger, men det var lett å lage redirect looper mellom Apache og Varnish (hvor nettleseren din blir sendt frem og tilbake mellom Apache og Varnish i all evighet) så vi valgte en annen metode. Vi installerte Hitch på serveren og konfigurerte den til å bruke et SSL/TLS sertifikat fra Let’s Encrypt. Hitch gjør ingenting annet enn å ta imot tilkoblingen, dekryptere den og sende forespørselen videre til neste ledd i prosessen.

Caching og reverse proxy

Nå som Hitch tar imot HTTPS så trenger vi å route forespørslene til riktig sted. Til det installerer vi Varnish. Varnish er egentlig en webcache, men programvaren har mange kraftige funksjoner som gjør det praktisk å bruke den som en proxy også.

Siden www.gathering.org består av to forskjellige biter i bakgrunnen trenger vi å proxye (videresende) alle forespørsler for https://www.gathering.org/api til WordPress, mens resten går til en Node.JS basert applikasjon på https://www.gathering.org/tg19. Fordelen med en reverse proxy her er at du som bruker av nettsiden bare trenger å forholde deg til en webadresse, mens webserveren som tar deg imot kan benytte mange tjenester i bakgrunnen uten at du legger merke til det.

Men hva er en cache? En cache er et mellomlager mellom deg og nettsiden som gjør responsen fra nettsiden raskere. Når du kobler til en webside så må webserveren generere en versjon av nettsiden for deg. Dette kan være en tung oppgave og kan ofte være treg. Det cachen gjør er å ta vare på en kopi av nettsiden, så når neste person spør om samme nettside så svarer Varnish bare med den mellomlagrede kopien istedenfor å la webserveren generere en helt ny en. Dette fungerer bare en liten stund, for etterhvert så endrer jo innholdet på nettsiden seg når det blir publisert nye artikler og slikt, så Varnish kan bare mellomlagre sider i maksimalt noen minutter. Kanskje bare så lite som noen sekunder hvis innholdet endrer seg fort. I www.gathering.org sitt tilfelle så lagrer vi dataen ganske lenge for vi har satt det opp slik at dersom noe innhold endrer seg så sendes det en beskjed til Varnish om å slette den mellomlagrede kopien.

Hva skjer etterpå?

Nå som forespørselen er kommet gjennom Hitch og Varnish så ender den enten opp direkte i vår Node.JS applikasjon eller så treffer den Apache som leverer WordPress siden. Totalt sett så ser arkitekturen vår slik ut.

Webserver arkitektur for www.gathering.org

Hvordan vi bruker WordPress og vår egenlagde frontend kommer vi nok tilbake til i en senere bloggpost (og kanskje kan du få tatt en titt på koden?).

Fiber, kabler, optikk og slik

06 Mar 2019, by from Tech:Net

Så hva er egentlig greia med fiber? Og hvordan funker det når vi drar tre nettverks-kabler fra en bordsvitsj (eller kantsvitsj) til distro-svitsjene som står i midtgangen? Jeg tenkte jeg kunne skrive litt om det! Selv om jeg eeeeegentlig ikke er den beste kandidaten, da jeg strengt tatt ikke jobber med dette til daglig og for det meste er eksponert til det på TG.

En liten rask påminnelse: Når jeg skriver om sånne nettverkskabler du plugger i PC’en så skriver stort sett TP-kabler – det står for “twisted pair”. Hver “leder” kommer i par – og de er tvunnet, skjær opp en gammel en og du vil se det med en gang.

Aggregater

Men uansett, la meg begynne med et aggregat!

Et aggregat, eller en port channel, eller en bundle, eller et bond, eller en av de mange andre navnene på samme ting er en måte å kombinere to eller flere fysiske kabler så de kan behandles som en på det logiske nivået. Dette gjøres vanligvis av to grunner: for å gjøre ting mer robust – når “naboen” din på TG drar ut kabelen som kobler hele svitsjen på internett nå så er det to til igjen – og for å øke båndbredden – 3Gbit/s i stedet for 1Gbit/s. Dette gjøres på et såpass lavt nivå i stacken at ting som ruting av IP-pakker ikke kommer inn i bildet.

Aggregater kan settes opp på vanlig TP-kabler, fiberkabler og egentlig det meste, litt avhengig av utstyret, så lenge begge sider er enige.

Det finnes grovt sett to måter å operere det på: Enten at alle medlemmer (kabler) i aggregatet er aktive samtidig, eller at en er aktiv og en annen er passiv, men tas i bruk ved feil.

Hvordan trafikken balanseres over flere kabler når alle medlemmer(kabler) er aktive varierer fra implementasjon til implementasjon. I dag finnes også standarden 802.3ad (og 802.3ax), som gjør ting lettere. Dette kan man sette opp manuelt – da er det åpenbart kritisk viktig at du setter det opp likt på begge sider. Et mye bedre alternativ er å bruke LACP – Link Aggregation Control Protocol. Med LACP må du fortsatt sette opp alt på begge sider, men failover skjer av seg selv og du er sikker på at begge sider ser ting likt.

Et eksempel på hva som skjer uten LACP hadde vi på… enten var det TG15 eller TG17. Vi satt i NOC’en og fikk et oppkall på radio fra et annet crew som trengte bistand… fordi de nådde bare halve internett! Bokstavelig talt. De nådde annenhver IP. Etter mye latter og undring sendte vi en for å se på det, og kunne bekrefte de heller utrolige symptomene. Dette skyldtes at de brukte en (eldre) svitsj som hadde gammel konfig på seg med statisk lastbalansering av et link aggregat. Med LACP ville ikke dette skjedd.

Men uansett, link aggregater og LACP er helt sentralt for både TG og internett som sådan. Vi bruker det på så og si alle linker vi har, inkludert mot internett – vi har 5 par med 10Gbit/s fiber mot Telenor, i ett aggregat.

Fiber

Så fiber da? Hva ER egentlig greia?

Vel, la oss begynne med TP. Hva er greia der?

TP er lagd for LAN. TP har en maks-lengde på 100 meter (stort sett kan du komme unna med mer enn 100 meter, men speccen sier nå maks 100 meter), og skal du ha raskere hastigheter må du ha ny kabel.

Nå ligger det litt i kortene, men fiber har helt annerledes egenskaper. For det første har fiber maks-lengder på et sted mellom 300 meter og 50 000 meter, avhengig av teknologi i bruk. Og vel så viktig: Fiber som ble lagt for evigheter siden kan fortsatt “oppgraderes” ved at du bare bytter ut utstyret på endene. For et LAN er ikke dette viktig: Det å trekke en ny kabel fra midten av vikingskipet til bordene er ikke vanskelig. Men om du har en 10km lang fiberkabel i en grøft så er det veldig fint å vite at du kan oppgradere hastighetene uten å bytte kabelen.

Fiberkabler brukes også på forskjellige måter, men den simpleste måten er å jobbe med dedikerte fiber-par. Så mellom to nettverkselementer kobles det to fiberkabler i et par: En for å sende data og en for å motta. Man snakker derfor ofte om “par” som om man mener kabel. Ikke helt ulik at en TP-kabel består av flere kobbertråder.

Men vi må snakke litt mer om dette med 300 meter versus 50km. Det er hovedsaklig to typer fiber man snakker om: multimode og singlemode. Dette kommer fra tykkelsen på “kjernene” i fiberen om jeg ikke tar helt feil, men det er i praksis ikke noe du tenker på. Den korte versjonen er uansett at du vil ha single mode.

For ordens skyld: Singlemode er typisk gul, mens multimode gjerne er hva som helst annet enn gul.

Multimode funker innad i bygninger, inne i et datasenter, osv. Typisk avstandsbegrensinger er alt fra 100 til 500 meter. Selv i vikingskipet er det ikke stort. Hovedgrunnen til at du finner mye multimode? Det er bittelitt billigere…. I dag er ikke forskjellen veldig stor.

Men en grunn til at multimode skaper problemer er at for både TP og fiber er det helt vanlig at man skjøter kablene. Dette gjøres i stor stil, både på TG, f.eks. drar vi fiberkabler fra distroene på gulvet og opp til taket, der skjøter vi dem inn på en permanent bunt fiberkabler som går ned til NOC’en. Men det skjer også på internett som sådan: Når det legges fiberkabler legges det så og si aldri en fiberkabel. Man trekker en samlingskabel – alt fra 4 par til over hundre. La oss si at man begynner med 96 par. Så i neste punkt skal kanskje dette deles – det skal kobles til flere forskjellige kunder, hver et godt stykke unna. Så man trekker to nye 96-pars kabler i “hver sin retning” – man har lagd seg en Y.

Neste ledd igjen kan det kanskje deles 3 veier, da gir det kanskje mer mening å bruke 24 par? Eller inn til kunden trekker man kanskje 8 par, selv om kunden foreløpig bare har planer om å bruke to.

Resultatet er at det er masse kabler i grøfter med “ubrukte” par. Men det er ikke koblet på noe i hver ende. Dette fordi det er dyrt å grave, så man vil helst slippe å gjøre det på nytt fordi man sparte på fiber.

Det meste av dette er da singlemode. Og du kan ikke koble singlemode og multimode sammen – da må du ha “aktivt” utstyr i mellom.

Littegrann WDM?

På lengre strekk må man også snakke om WDM “wave division multiplexing” – der man sender flere signaler på samme kabel, med forskjellige “farger”. Fiber, som du sikkert vet, bruker lys i stedet for elektriske signaler. Lys overføres med en bølgelengde – som også er det samme som farge. Ved å multiplexe lys med forskjellige farger kan man sende forskjellige, ellers uavhengige, signaler på samme fysiske fiberkabel. Dette krever en del kostbart utstyr, men er slik internett sin ryggrad er bygd opp.

Som en liten sidenote: Når folk snakker om “sort fiber” så mener man et fibersignal uten WDM som går fra A til B. Det er for eksempel sort fiber mellom vikingskipet og Telenor-ruteren som TG får internett fra. Merk at det ikke trenger å være bare EN kabel. Mellom TG og Telenor f.eks. er det flere skjøtepunkter i bakken.

Men vi bruker ikke noe WDM for TG. Så la oss holde det utenfor. (Vent…. for sent!)

Vi bruker derimot singlemode. Vi har både permanent installert fiber som ligger der hele året, og en hel masse “patch” på alt fra 1 meter til 50 meter. Patchekabler er “løse” kabler som er ferdigterminert (har plugger) og kan beskrive alt fra kabelen du bruker mellom pc’en din og hjemmeruteren din, eller fiberkabler vi bruker mellom våre rutere. For å gjøre det lettere å koble ting har man “patchepaneler”, dette er paneler med masse kontakter (hun-siden) som lar deg koble patchekabler på mer permanent installerte kabler.

I ringen vår (se forrige post fra meg!) så har vi 6 par i en G12-kabel (12 fiber, 6 par). Dette har vi terminert “fint” i patchepaneler så det er lett å koble på annet utstyr. Dette betyr at for å faktisk bruke det må vi ha minimum 3 fiberkabler i bruk: 1 patchekabel fra nettverksutstyret til punktet i patchepanelet – deretter G12-kabelen som går mellom 2 patchepaneler – og enda en patchekabel og nettverksutstyr igjen. Opp til taket og mellom Tele og NOC er det en G48 som ligger – det er da 24 par.

Plugger?

Men hva med pluggene?

Det jeg har jobbet mest med på TG er LC og SC – to ganske like plugger, et triks for å huske forskjellen LC er liten og SC er stor. Inn i utstyret er det stort sett LC.

Dette er bare plugger – om man vet hva man gjør kan man kappe en fiberkabel og bytte om plugger.

For de litt større kablene bruker vi MPO – her herjer det litt forvirring, men MPO er egentlig selve pluggen/kontakten som gjør det enkelt å koble f.eks. en 6-pars kabel inn i en “kasett” som splitter det ut til 2*6 LC-plugger. For å være ærlig så husker jeg ikke helt hvor vi bruker SC (de litt større pluggene), men selve utstyret bruker LC. Og begge pluggene er ganske like og typisk blå.

Distro

Her ser du en typisk distro. Det grå er vanlig TP patchekabler, den lille boksen på toppen med 4 gule kabler i seg er en MPO-kassett, de fire gule kablene er to par med single-mode fiber som går ned i hver sin EX3300. Mellom EX3300’ene kan du se noen sorte DAC-kabler på høyre side i bildet.

Transceivere

Så har vi kommet til hjertet: optikk! Eller, nesten da.

Med TP er det bare RJ45 tut og kjør, men for å kunne støtte både multimode, singlemode, wdm, DAC-kabler (Dette har jeg ikke nevnt en gang! DAC-kabler er typisk kobber, lagd for korte avstander, typisk fra en server til nærmeste switch) med mer, så fant man for lenge siden ut at det er lurt at man lager et generelt grensesnitt som lar deg plugge inn “kabel-spesifikke” moduler. Dette begynte vel formelt med GBIC’er, men i dag snakker vi om varianter av SFP – small form-factor pluggable module.

Tanken er enkel: Du lager en svitsj med f.eks. 4 10Gbit/s-porter, men selve porten er helt ubrukelig alene. Du må kjøpe en “transciever”(transmitter/receiver) for å sette inn i porten. Skal du bruke “sort fiber” kjøper du bare to transcievere som jobber på samme bølgelengde og setter i hver ende. Skal du ha WDM må hver transciever ha hver sin unike farge (og du må ha noe WDM-utstyr også).

Med DAC-kabler har man på en måte juksa: Da har man to transcievere og en integrert kabel i mellom.

Optikk vi bruker kommer hovedsaklig i to-tre varianter: SFP – dette er 1Gbit/s, vi bruker i praksis ikke dette, men trenger det. SFP+ er 10Gbit/s, dette bruker vi plenty av. QSFP+ – quad SFP+ – 40Gbit/s – dette bruker vi noe av også, også har man vel også fått diverse ala QSFP28 som gir 100Gbit/s – men det bruker vi ikke på TG. GBIC er gamle greier som kom før SFP, men en del bruker begrepet fortsatt om ting som ikke egentlig er GBIC – don’t be that guy. Du får også tak i TP-moduler! Så du kan sette inn moduler som gir RJ45 – eller fiber.

En enkel transciever koster alt fra 100kr til 10 000,-, om du handler “fornuftig”. Om du tror på listepriser, derimot, så koster juniper sine 40G-transcievere 7k USD per stykk – noe intet fornuftig menneske betaler.

Optikk
(Her er original-optikk vi lånte fra Juniper til en listepris av 7k USD per stk…. nei, du betaler ikke 7k USD for dem om du faktisk kjøper dem selv)

Slike slotter er stort sett aldri foroverkompatible. Du kan ikke sette en SFP+ modul inn i en SFP-slot og tenke at “det går bra, jeg får vel bare 1Gbit/s i stedet for 10Gbit/s”. Det går ikke.

På en annen side kan du gjerne ta en QSFP og koble på en “fan-out” modul for å få 4 stk 10Gbit/s i stedet for 1 stk 40Gbit/s.

Og når vi er inne på det…. I tillegg til at hver port krever en modul er det også vanlig at dyrere nettverksutstyr lar deg bytte ut hele grupper med porter – på virkelig store rutere snakker man gjerne om “linjekort”. Du kan da kjøpe et linjekort med masse 10Gbit/s SFP+ for eksempel, eller et linjekort med 8 100Gbit/s porter. Her er det virkelig mulig å fremtidssikre seg: Det kommer gjerne nye linjekort lenge etter en avansert ruter er sluppet. Selv på “mindre” bokser, som de vi bruker som distro på TG, er det små moduler vi kan bytte eller kjøpe til.

Linjekort kommer også i flere forskjellige varianter, hovedsaklig delt i to kategorier: Linjekort som gir deg flere interface/porter, og linjekort som gir deg flere “Features”. Sistnevnte er i grunnen “CPU”en til en ruter. På TG har vi en Juniper MX480-kjerneruter som vi kjører to “routing engines” (RE’er – eller cpu’er), der den ene er backup for den andre. Disse routing engine-kortene er virkelig en fullverdig PC. Intel CPU’er og RAM og i grunnen det du kan forvente, men spesialisert hovedkort. Slike linjekort kan byttes “i fart”, så vi har ganske god sikring her.

Så egentlig er MX480’en “bare” et chassis med et bakpanel som lar linjekortene kommunisere lynraskt. Og 4 strømforsyninger (som vi kobler på 4 forskjellige sikringer).

MX480

Her har vi en MX480 med to RE’er og to linjekort med 10Gbit/s-porter til deltakeredistroer og 40GBit/s til resten av nettet.

About

TG - Technical Blog is the unofficial rambling place of the Systemstøtte and Tech crews from The Gathering.

Related sites

Collaborators