God dag!
Fekk tilbod om å skrive om Game og kva teknisk utstyr og programvare me brukar, takkar sjølvsagt ja!
Server Hardware:
I år har vår kjekke snille sponsor Nextron ordna fysiske serverar til Game, kontra tidlegare har me hatt virtuelle maskinar til å køyre programvare. Det blir totalt 5 serverar der 2 er til CS og 3 er til Minecraft, der ein av dei er ein reserve i tilfelle dei to andre skulle slite med noko. Me kjørar SSD’ane i software RAID1 for pålitelegheit, og har tilgang til serverane via IPMI. Spesifikasjonane er som følgjande:
Game – CS:GO #1
20 core Intel Xeon E5-2640v4 2.40GHz
64 GB
2×1 TB SSD
2×10 GbE SFP+
Game – CS:GO #2
20 core Intel Xeon E5-2640v4 2.40GHz
64 GB
2×1 TB SSD
2×10 GbE SFP+
Game – Minecraft #1
Intel Core i7-7820X 3.60GHz, turbo 4.3GHz/4.5GHz
64 GB
2×1 TB SSD
2×10 GbE SFP+
Game – Minecraft #2
Intel Core i7-7820X 3.60GHz, turbo 4.3GHz/4.5GHz
64 GB
2×1 TB SSD
2×10 GbE SFP+
Game – Minecraft ekstra
Intel Core i7-7820X 3.60GHz, turbo 4.3GHz/4.5GHz
64 GB
2×1 TB SSD
2×10 GbE SFP+
I tillegg har me to mindre VM’ar på 4GB RAM, 50GB HDD og 2vCPU kjerne som skal køyre kontrollpanelet til serverane, det snakkar me om vidare
*
Server software:
*
I år skal båe Minecraft og CS køyrast med pterodactyl, noko som er nytt for CS på TG. Med to like system vil eventuell feilsøking av pterodactyl truleg gå betre, då me har fleire i crew med kompetanse for pterodactyl. Om det ikkje går som planlagt, har me og ein fallback løysing CS systemet som kjørte forrige TG. For dei som er ukjent med det, er pterodactyl ikkje eit legemiddel (som eg først trudde) eller ein dinosaur (som Kristian trudde), men eit management panel til spel-serverar. Programvaren har open kjeldekode og tilbyr ein haug med funksjonar frå kontrollering av fleire nodar, API kontroll, rask distribuering av serverar og mykje meir. Det er docker basert, så ein kan skrive eigen docker bilete ein kan distribuere, som me gjer. Meir info hos https://pterodactyl.io/
CS og Minecraft køyrar uavhengig frå kvarandre med eiget panel på kvar sin virtuelle maskin. Det er fullt mogleg å køyre båe Minecraft og CS serverar via eit panel, dog. Det panelet er då kopla til dei fysiske serverane våre som node, der me installera OS, docker, daemon, og lastar opp konfigurasjonsfila for å kople oss på. På nodane kan me då få opp docker bileta som køyrar sjølve spel-serverane. Oppsettet kan likne noko sånt:
Me brukar da 32 serverar til CS fordelt på to nodar, og har ressursar til meir om det skulle meldast på fleire lag. Samstundes kan me køyre opp til 128(!) Minecraft serverar.
CS maskinane kjem til å kjøre GO:TV Relay sånn deltakarar kan sjå stream direkte frå ein spelar om vedkommande ynskar, framfor gjennom Twitch o.l.
Eit anna system me brukar er Unicorn (Unified Net-based Interface for Competition Organization, Rules and News, phew). Unicorn er konkurransesystemet til TG laga for å drifte konkurransane på The Gathering frå ein deltakar ynskjer å delta, fram til han står på scena med premien sin. Det blei først brukt i 2015 og er stadig oppdatert med nye funksjonar og optimalisering.
Backend til Unicorn er skrevet i PHP med ein MySQL database server. Frontend er enn so lenge tett kopla saman med backenden, og brukar ein MVC modell med Smarty templating. Planen på sikt er å skilje front og backend og heller gå over til ein React (eller liknandes) basert frontend. Til fillagring nyttar me oss av tus.io for opplasting av store filar. Dette gir oss moglegheita til å gjer kontinuerlege opplastingar om ein opplasting skulle feile. Deretter flyttast filar over i AWS S3 som blir brukt som eit CDN gjennom AWS CloudFront.
Creative sine konkurransar handterast direkte gjøna UNICORN, der administratorar kan administrere alle aspekt av sine konkurransar. Dette inneberar alt i frå oppretting av konkurranse, mottak av bidrag med kvalifisering & diskvalifisering, resultatavlesning osv. For game har me i tillegg implementert støtte for Toornament som handtera brackets.
Bruk av API:
Til Minecraft brukar me Unicorn. Med Minecraft sendar me queries mot Unicorn sitt API som hentar ut påmeldte lag. Om den finn eit lag, sendar den requests mot pterodactyl og opprettar server. Etter den er oppe og går, sendar systemet kommandoar for oppsett av serveren. CS brukar eBot til administrering, start/stopp av match samt som dei samlar demo og loggar som i atterkant kan bli brukt til å lage fine grafar og statistikk
Eg håpar denne gjeste-artikkelen har vår til hjelp for folk som undrar på det tekniske bak game, og for folk som ynskjer å søke hos oss i CnA (Competitions and Activities)!
Spesiell takk til Jo Emil Holen for å dele mykje informasjon angåande Unicorn!
Og stor takk til alle i Game som var med på å fortelje om deira sine tekniske oppgåver og system me brukar!
Jeg vekket akkurat contrib.gathering.org til live, men dette blir en to-delt blog-post.
Hva er contrib.gathering.org?
La oss begynne med det viktigste: contrib.gathering.org er en samling linker til ting som er løst relatert til TG. Jeg håper lista vil eksplodere, etter hvert som alle dere der ute som lager ting får lagt til innholdet deres. Hjelp oss!
Den enkleste måten å gjøre det på er via github. Helst kan du lage en pull request, men et vanlig issue virker selvsagt også.
Vi håper å få samlet så mye artige linker (relatert til TG som mulig). Bildegallerier, konkuransebidrag, eller hva det måtte være. Bruk fantasien!
Del to: Deploy
Den andre delen av denne posten er stacken som ligger bak. Tidligere har alt vi hoster på TG stort sett ligget på den samme enorme serveren, men nylig har vi begynt å bevege oss over i litt mer moderne metoder. Contrib er foreløpig den desidert mest moderne pipelinen vi har. Den vil forhåpentligvis være et positivt bidrag for å få flyttet andre, viktigere websider over til mer moderne og fleksible utviklingsmiljøer.
Selve biten med rst2html og sånt for å generere html er ganske lite interessant.
Det som er artig er at dette kjører på Kubernetes. I dag kjører det på Google Cloud, men det kan selvsagt kjøre andre steder også – vi prøver ut Google Cloud først.
For å deploye til “prod” er alt vi trenger å gjøre i dag å comitte til master-branchen i git, når det skjer så trigges en automatisk bygg i Google Cloud, som avslutter med å gjøre en deploy i kubernetes-clusteret (også i google cloud). Denne deployen gjøres med en rolling update.
I dette tilfellet er det forholdsvis overkill, siden det ikke er noe kode bak – bare statiske filer – men det er en fin test, og vil gjenbrukes for andre prosjekter.
For de interesserte så ligger alt for deployment i samme git-repo. En rask gjennomgang:
~~~~.text
- /Dockerfile – Denne brukes til å bygge en
container, den kan kjøres på din lokale laptop om du vil
- /cloudbuild.yaml – Dette brukes av den automatiske
byggeprosessen. Kort fortalt definerer den at ved
en ny git commit skal det gjennomføres en docker build,
push og kubernetes deploy.
- /k8s/ – Dette er ressursene som er lagt opp i Kubernetes.
De er i utgangspunktet bare lagt til en gang for hånd,
eller ved endringer.
- /k8s/deploy.yaml – dette er selve deploymentfila, som i
praksis bare definerer hvilket image vi skal bruke. Imaget
oppdateres automatisk av byggescriptet.
- /k8s/service.yaml – Her gjør vi deploymenten tilgjengelig for
andre tjenester i clusteret
- /k8s/ingress.yaml – Denne definerer at tjenesten skal
eksponeres på internett, via “ingress”-tjenesten. Den
spesifiserer domenet, og ber om SSL-terminering, via
let’s encrypt.
~~~~
(Jadda, flott med en blog der bullet points er brukket)
Det som ikke ligger i det repoet er resten av infrastrukturen: ingress-kontrolleren og let’s encrypt automatikken. Dette kan det hende det kommer mer om når det faktisk er 100% ferdig. Teknisk sett kjører alt dette på min personlige gcloud-konto/cluster i dag…. Fordi jeg glemte igjen login/passord til KANDU/TG sin konto på jobben (… glemte “pass git push”, for de nysgjerrige).
Wannabe er et evig mysterium. En stor dinosaur med svære misfostrede armer og bein, en ekstra hale og noen store, unormale kuler. Kort fortalt så er Wannabe TGs “management-system” for frivillige.
Wannabe?
De fleste kjenner nok Wannabe som det systemet der man søker seg inn i crewet på TG. Fyller ut side opp og side ned med utrolig finskrevet og bearbeidet tekst, i håp om at man kanskje endelig kommer inn i crewet, eller i håp om at man får fortsette å være med. (misforstå meg rett her, vi trenger maange i crew). Systemet lar deg så vente, noen venter litt, andre venter lenge. Og plutselig en dag får man en slik velkomst-mail fra Wannabe om at “tjohei, kom å bli med i crew, da!”. Da har Wannabe gjort sitt for deg, tenker du. Nå er Wannabes funksjonalitet for deg bare en enkel liste over hvem du er crew-buddies med.
Men hva ANNET brukes Wannabe egentlig til?
Som du sikkert las øverst så er Wannabe en dinosaur. Og med det så menes det at på et eller annet tidspunkt ble bestemt at alt skal styres fra Wannabe. Du har naturlige funksjoner som hører til i Wannabe, som behandling av crew og søknader, utsendelse av SMS, epostliste-administrasjon, oppmøte, ernæring og medisinsk informasjon og lignende. Men så har du jo også ting som Logistikk-systemet til TG, lost and found, Akkrediterings-modul, sovekart og styring av infoskjermer.
Det betyr at: en deltaker har mistet noe, hva gjør crewmedlemmene som skal sjekke etter det? De bruker Wannabe. Når en skal dele ut akkreditering til en journalist, hva må du gjøre? Logge deg på Wannabe. Du vil oppdatere sovekartet? Logg deg på Wannabe. Få ut informasjon til deltakerene via de mange info-skjermer? Logg deg på Wannabe.
Et flott kaos..
Du må virkelig ikke misforstå meg her, fordi Wannabe er et veldig bra system, med sin egen lille sjarm. Det er bare en dinosaur. Og som alle andre dinosaurer så er de svære, vanskelig å ha med å gjøre og trøblete å ha oversikt over. Men det funker! Wannabe fungerer, gjør det det skal og bare tråler videre.
Systems sin oppgave i dette
Vi er jo Systems, og vi skal ha kontroll på dette. Vi administrerer alle modulene, oppdaterer de, vedlikeholder de og gir de den etterlengtede kjærligheten de trenger. Vi gjør også andre ting, som å gi tilganger og godkjenne profilbilder.
Wannabes fremtid
Det som er “inn” i dag er jo mikrotjenester, la frontend skrike til backend igjennom et RESTful API, som naturligvis er stateless og famler i mørket. Det er nok også dit Wannabe skal, om noen år. Segmentering av tjenestene som Wannabe tilbyr er nok en av de beste veiene å gå. En egen liten by av docker-konteinere som snakker sammen og samarbeider i harmoni for å gi brukeren det en måtte ønske. Ahh, for en flott fremtid..
Og til syvende og sist så prøver vi bare å ha system..
get it? Systems, system? Eh….
Vi ses på TG!
I fjor samlet vi hele 40 personer fra LAN miljøet rundt om i Norge. Initiativet fikk gode tilbakemeldinger og det virket som et fornuftig initiativ.
Vi ønsker i år som i fjor å samle teknikere fra hele Norges LAN/Dataparty-miljø. Dette er lavterskel, det eneste vi ønsker er at de som deltar har vært med teknisk på et arrangement før. Det kan være et med 10 deltakere eller 10 000. Spiller ingen rolle.
Agendaen blir ganske løs som i fjor. Har du noe du på hjertet og ønsker prate om så er det ingenting i veien for det.
Sannsynligvis kommer dette til å skje på Fredag og vi kommer til å stille med et rom og trolig noe å tygge på.
Høres dette interessant ut? Påmelding finner du her: https://goo.gl/sLCRpY
Om du bare kommer for meetupen kan det hende vi kan ordne noen dagsbiletter, men vi kan ikke garantere noe enda da vi må se ann pågangen litt. Ta kontakt, så finner vi ut av det!
Har du noen ytterligere spørsmål eller kommentarer så ta gjerne kontakt med oss via meetup@gathering.org
The Gathering has almost come to an end and it’s about time we posted some details about our network design.
Network design
Our network is designed in the traditional three-layered hierarchical model with the core, distribution and access layer where L3 is terminated at our distribution.
Core layer
The core L3 switches consists of 2x Juniper QFX5100 in a virtual chassis, which is Junipers stacking technology. In addition to provide our distribution with uplinks, the core switch also connects our 80Gig backbone ring with our stand and border router.
Between our border router the internet we have an inline Juniper SRX5800 which is capable of pushing 2Tbps worth of firewall throughput(!). This is where we terminate our BGP peering with Telenor and do route redistribution to OSPF, making the SRX our OSPF ASBR.
Distribution Layer
The L3 distribution switches consists of 3x Juniper EX3300 in a virtual chassis per distribution. It connects to the core using 2x 10Gbps singel-mode transceivers patched into our MPO cassettes pulled from the ceiling. The distro redistributes its connected routes into the OSPF area and advertises it to the core.
Access layer
The L2 access switches consists of 144+ Juniper EX2200 with a 3x 1Gbps connection to our distribution. To protect our network at the edge, we run a series of security features collectively called first-hop security. This takes care of a lot of potential issues such as loops, spoofing and ARP-poisoning.
vc1.ring
One of the design choices this year was to turn our backbone ring, which traverses the entire arena, into a virtual chassis instead of separate routers. This effectively means that it becomes a distribution switch for our crew network. This makes it easy for us to provision edge/access switches to our sponsors and crew areas. As a result we have for the first time ever provisioned our entire access network. Not a single access switch has been configured manually this year!
Internet capacity
TL;DR – 40Gbps…
At TG16 we suffered several DDoS attacks towards our network and even our website (gathering.org). In order to be able to handle a potential DDoS attack this year we decided to upgrade our internet capacity from 40Gbps to 40Gbps + 10Gbps, where the newly added 10Gbps-link would be reserved for our production environment. Instead of dedicating a single physical interface, we decided to include the interface in our aggregated interface and rate-limit our participants network to 40Gbps. This way we keep our production network alive when our participants network gets lit up.
The party is well underway, and I was dumb enough to say aloud the phrase “We should probably blog something?”. Everyone agreed, and thus told me to do it. Damn it.
Anyway, things are going disturbingly well. We were done with our setup 24 hours ahead of time, more or less. I’ve had the special honor of being the first to get a valid DHCP lease in the NOC and the first to get a proper DHCP lease “on the floor”. And I’ve zeroized the entire west side of the ship (e.g.: reset the switches to get them to request proper configuration, this involved physically walking to each switch with a console cable and laptop).
But we have had some minor issues.
First, which you might have picked up, we have to tickle the edge switches a bit to get them to request configuration. This cost us a couple of hours of delay during the setup. And it means that whenever we get a power failure, our edge switches boot up in a useless state and we have to poke them with a console cable. We’ve been trying to improve this situation, but it’s not really a disaster.
We’ve also had some CPU issues on our distribution switches. Mainly whenever we power on all the edge switches. To reduce the load, we disabled LACP – the protocol used to control how the three uplinks to each edge switch is combined into a single link. This worked great, until we ran into the next problem.
The next problem was a crash on one of the EX3300 switches that make up a distribution switch (each distribution switch has 3 EX3300 switches in a virtual chassis). We’re working with Juniper on the root cause of these crashes (we’ve had at least 4 so far as I am aware). A single member in a VC crashing shouldn’t be a big deal. At worst, we could get about a minute or two of down-time on that single distribution switch before the two remaining members take over the functionality.
However, since we hade disabled LACP earlier, that caused some trobule: The link between the core router and the distribution switch didn’t come back up again because that’s a job for LACP. This happened to distro7 on wednesday. We were able to bring distro7 up again quite fast regardless, even with a member missing.
After that, we re-enabled LACP on all distribution switches, which was the cause of the (very short) network outage on wednesday across the entire site.
Other than that, there is little to report. On my side, being in charge of monitoring and tooling (e.g.: Gondul), the biggest challenge is the ring now being a single virtual chassis making it trickier to measure the individual members. And the fact that graphite-api has completely broken down.
Oh, and we’ve had to move our SRX firewall, because it was getting far too hot… more on that later?
This time, there were no funny pictures though!
This year our wireless seems to be alot more stable then ever before.
Unfortunately i’m not much of a wireless-guy myself, so i can’t go into all the details, but i just felt like writing a small post about our wireless anyway.
This year we have Fortinet onboard to provide us with equipment for the wireless network.
The equipment we use consists of a total of 162 FortiAP U421EV (deployed) and 2 FortiWLC-3000D.
As of right now we have 1517 clients, where 1487 of them are on 5GHz and 30 on 2.4GHz.
The 2.4GHz SSID is hidden and mostly used for equipment that don’t support 5GHz, like PS4 for example.
We have performed some testing by roaming around the vikingship and got an average of 20ms latency and 35-ish Mbps. Our Wireless guy almost managed to watch an entire episode on Netflix without major disruption while walking around!
The accesspoints are spread evenly across the Vikingship.
We have one accesspoint at the end of every second row on each side of the vikingship, as well as one accesspoint per row on each side.
Well.. it’s kinda hard to explain in words, so have a low-quality picture from my phone of our drawing board in the NOC:
The red dots across the tables represents the AP placements in the main area of the vikingship.
Below you can see a map with the AP placement from our wireless controller.
Well.. as i said i’m not much of a wireless guy, but i hope you got some interesting information about how our wireless is deployed this year.
If you have any questions regarding Wireless at TG17, feel free to contact us on the official discord server for The Gathering, channel #tech 🙂
And meanwhile, we are on the lookout for trouble.
Our lights in front of the NOC has turned green!
All edgeswitches are now up and running.
We will perform some tweaks and do a DHCP-run shortly.
See you soon!
Glenn is amazed by the servers. Or lights. Or both. To much coffee?
Thank you Nextron, for blazing fast servers!
Photo: Joachim Tingvold