PROJEKTRAPPORT O-RINGEN 2011 Författare: Anders Richter DD09 Carl Folkesson DD09 Daniel Johansson DD09 Frank Svensson DD09 Fredrik Ankarstrand DD09 Fredrik Hulth DD09 Niklas Bogeholm DD09 Niklas Eriksson DD09 Examinator: Erik Gunnarsson Utskriftsdatum: 2011-08-17
Sammanfattning Sammanfattning O-ringen är ett evenemang som går av stapeln varje år under vecka 30 och är världens största orienteringsarrangemang. Evenemanget går av stapeln på olika platser varje år och detta år återvänder tävlingen till Mohed, på denna plats utspelades O-ringen 2006. Tävlingen består av fem etapper varav etapp ett och två går i Glössbo, etapp fyra och fem i Böle och den sista etappen avgörs i Mohed. Målsättningen för projektet var att tillhandahålla avbrottsfri drift och konfiguration av ett nätverk samt ett antal tjänster för O-ringen tävlingens bruk under perioden 20-29 juli. Det som skulle leveras var: Trådlöst lan med internetaccess i O-ringenstaden samt på Arenorna Installation av OS och programvara på ett hundratal Klienter Drift av Tävlingens Hemsida, O-ringenononline Drift av OLA och Tävlingsdatabasen Support och Felsökning på plats Nätverket designades med målsättningen att skapa redundanta lösningar så långt det var möjligt och fyllde en funktion, detta var dock inte möjligt vid WAN-länken ut mot internet och därmed även VPN-tunneln mellan arenan och staden. På arenan och i staden finns dock redundanta länkar överallt. Sannolikheten att de tävlande skulle påverkas vid ett hård- eller mjukvarufel är mycket liten och ändringar kan göras utan större avbrott i funktion eller tjänster. AD, DNS, DHCP, SQL och OLA är nödvändiga tjänster för att uppfylla vårt mål samt göra det lätt och funktionellt för användarna. Minst en redundant server används för samtliga tjänster. Arbetet har delats upp i de tre grupperna Core, Services och Access Core-gruppen inriktade sig på redundans, säkerhet, routing, VPN-tunnlar, VLAN och WANkopplingar. Service-gruppen jobbade med OLA, AD, DNS, DHCP och MySQL Access-gruppen konfigurerade WLC s, laborerade med AP s, förberedde ghostning av klient-pc s, ansvarade för övervakningen samt konfigurerade access-switchar 1
Innehållsförteckning Innehållsförteckning 1 Inledning... 4 2 Mål... 5 3 Bakgrund... 6 3.1 O-ringen 2011... 6 3.2 Etapper... 6 4 Teori... 7 4.1 Access... 7 4.1.1 Power over Ethernet (PoE)... 7 4.1.2 Wlan... 7 4.1.3 Vlan... 7 4.1.4 Ghost... 8 4.1.5 VoIP... 8 4.2 Core... 9 4.2.1 VPN... 9 4.2.2 Brandvägg... 9 4.2.3 HSRP... 9 4.3 Services... 10 4.3.1 Cacti... 10 4.3.2 Active Directory... 10 4.3.3 MySQL... 11 4.3.4 OLA och SPORTident... 11 4.3.5 DNS... 11 4.3.6 DHCP... 12 4.3.7 NTP... 12 5 Planering och genomförande... 13 5.1 Access... 14 5.1.1 Switchar... 14 5.1.2 Trådlöst lan... 14 5.1.3 Voip... 15 5.1.4 Ghostning... 16 5.2 Core... 18 5.2.1 Nätverksplan... 18 5.2.2 Vlan och IP-planering... 20 5.2.3 Säkerhetslösning... 21 5.3 Services... 22 5.3.1 Serverplan... 22 5.3.2 Active Directory... 23 5.3.3 DHCP... 24 5.3.4 OLA + Mysql... 25 5.3.5 Övervakning... 26 6 Resultat... 27 6.1 Services... 27 6.1.1 Övervakning... 27 6.1.2 Active Directory... 27 2
Innehållsförteckning 6.1.3 OLA och MySQL... 27 6.1.4 OringenOnline... 28 6.2 Access... 28 6.2.1 Ghost... 28 6.2.2 Trådlösa nätverk... 29 6.2.3 IP-telefoni... 30 6.3 Core... 30 6.3.1 Nätverket... 30 6.3.2 Stadsnätet felar... 31 6.3.3 Team Sportia... 31 6.3.4 Beställning av Utrustning från Cisco... 31 6.3.5 Proxy ARP... 32 7 Bilagor... 33 3
Inledning 1 Inledning O-Ringen är världens största orienteringsevenemang med upp till 20000 deltagare årligen. Evenemanget arrangeras varje år under sommaren, varje år på ett nytt ställe. Detta år arrangeras O- ringen i Mohed och mediebevakningen brukar vara stor och evenemanget är välbesökt. Studenter som läser datanätteknik på Tekniska Högskolan i Jönköping har under ett flertal år fått möjligheten att genomföra sin avslutande praktikperiod på uppdrag av O-ringen. Detta uppdrag medför stort ansvar då ett misslyckande leder till problem för orienterarna och arrangörerna. Det är också ett mycket lärorikt projekt där man ges möjlighet att designa, implementera och drifta hela O- ringens nätverk samt servrar under evenemanget. Något man kan ha stor nytta av i sitt framtida yrkesliv. Tidigare årskullar har lyckats genomföra uppdraget på ett tillfredställande sätt och det är därför Studenter även år 2011 fått denna möjlighet. Vi är åtta studenter som detta år antagit uppdraget och denna rapport redogör för vår målsättning, teoretiska begrepp, hur arbetet planerades, hur det genomfördes samt det slutgiltiga resultatet. 4
Mål 2 Mål Orienteringstävlingen O-ringen har beställt avbrottsfri drift och konfiguration av ett nätverk samt ett antal tjänster för tävlingens bruk under perioden 20-29 juli. Följande skall levereras: Trådlöst lan med internetaccess i O-ringenstaden samt på Arenorna Installation av OS och programvara på ett hundratal Klienter Drift av Tävlingens Hemsida, O-ringenononline Drift av OLA och Tävlingsdatabasen Support och Felsökning på plats 5
Bakgrund 3 Bakgrund För projektgruppen är O-ringen 2011 ett projekt med stort fokus på att få den tekniska nätverksbiten att fungera. Detta har varit gällande även tidigare år och föregående projektgrupper har lyckats utföra uppdraget på ett tillfredställande sätt. Detta har föranlett att O-ringen åter igen har kontaktat JTH för att få nuvarande års studenter att arbeta med O-ringen under 2011. Projektet är uppdelat på två praktikperioder och 2 veckor under själva evenemanget. 3.1 O-ringen 2011 O-Ringen är världens största orienteringsäventyr med upp till 20000 deltagare årligen. Evenemanget arrangeras varje år i juli, vecka 30, varje år på ett nytt ställe. Detta år arrangeras O- ringen i Mohed. Det är inte första gången evenemanget går av stapeln här. 2006 hölls O-ringen på samma ort och blev en succé. Mediebevakningen brukar vara stor och evenemanget är välbesökt. Orienterare från hela världen samlas här för att mäta sina krafter i olika etapper med skiftande terräng. Tävlingarna är indelad i åldersgrupper och banorna på de olika etapperna är indelade i olika svårighetsgrad. Orienterarna använder en löparbricka för kontrollregistrering, denna stoppas in i en enhet vid varje kontroll. 3.2 Etapper Förra gången O-Ringen gick i Hälsingland var det cykel och gångavstånd till alla etapper. Denna gång blir avståndet något längre. Etapp ett och två arena Glössbo Det kommer att vara elva kilometer från O-Ringenstadens centrum ut till tävlingsarenan i Glössbo. Etapp tre och fyra arena Böle Till veckans tredje och fjärde etapp i Böle är avståndet från O-Ringenstaden 5,5 kilometer. Etapp fem arena Mohed Sista etappen avgörs i direkt anslutning till O-Ringenstaden. 6
Teori 4 Teori 4.1 Access Accessgruppen fokuserade på den teknologi som slutanvändare och klienter kommer i kontakt med, följande rubriker kommer att ge en grundläggande genomgång av PoE, Wlan,Vlan,VoIP och Ghostning. 4.1.1 Power over Ethernet (PoE) Power over Ethernet(PoE) är en teknik som används för att möjliggöra att ström tillsammans med datatrafik kan överföras via en ethernetkabel på ett säkert sätt. På så vis kan man elförsörja enheter som exempelvis IP-telefoner. Det räcker med att de är kopplade till en enhet som stödjer PoE. Detta kan vara till exempel en ethernetswitch. PoE förenklar därmed kabeldragning signifikant genom att eliminera behovet av separat elförsörjning. Tekniken används alltså mot slutanvändare och inte på nätverksutrustning. Däremot krävs det ofta att båda ändar stöder PoE, även om det också finns externa enheter som kan fungera som kraftomvandlare mot slutanvändaren. 4.1.2 Wlan Wireless Local Area Network(WLAN) är en term som beskriver olika typer av trådlösa nätverk. Den vanligaste uppsättningen är att enheter ansluter till en Access Punkt(AP) för att få tillgång till nätverket. Kryptering och säkerhet är väldigt viktigt när det gäller trådlösa nätverk. Intrång blir annars en relativt enkel handling och därefter kan man komma åt och utnyttja diverse resurser. De krypteringar som finns är WEP, WPA och WPA2. WPA2 är att föredra över de andra två eftersom den är säkrare än WEP. WPA2 använder tillskillnad från WPA algoritmen AES(Advanced Encryption Standard), istället för den underlägsna DES(Data Encryption Standard). Det är vanligt att man inom professionella nätverk sätter upp en central lösning när det gäller WLAN. Man använder sig då av en Wireless LAN Controller(WLC) där man sedan kan koppla in och hantera flera stycken Access Punkter. 4.1.3 Vlan Virtual Local Area Network, VLAN, används för att dela upp fysiska nätverk i virtuella grupperingar. Detta skiljer trafiken i det fysiska nätverket åt, eftersom broadcasttrafik endast flödar inom enskilda virtuella grupperingar. Tekniken finns att tillgå på switchar men eftersom de virtuella nätverken fungerar som fysiska, krävs routing av paket på lager 3 för att kontakt ska kunna ske mellan olika VLAN. Detta gäller även för VLAN som finns på samma switch. Routing mellan VLAN kan lösas med antigen en separat router (router-on-a-stick) eller via SVI:er, vilket kräver en lager 3 switch. Det finns olika teorier kring uppbyggnad av nät i hänsyn till VLAN. Principerna som finns kallas End-to-end samt Local VLAN. I End-to-end VLAN finns samma VLAN på alla switchar som är inblandade. I Local VLAN låter man istället ett VLAN endast befinna sig lokalt på varje switch, vilket innebär att exempelvis ett VLAN med ID 10 inte är samma virtuella nätverk som andra VLAN med ID 10 som befinner sig på andra switchar. 7
Teori Bilden beskriver End-to-end VLAN, Observera att varje VLAN motsvaras av ett subnät. 4.1.4 Ghost Benämningen Ghost (General Hardware-Oriented System Transfer) kommer ifrån Symantec s programvara med samma namn. Programvaran tillåter att imagefiler skapas som avbildar en hårddisk. Dessa kan sedan klonas från andra datorer, vilket utgör ursprunget av termen Ghostning. Imagefilen återskapas via andra datorer genom antigen nätverksboot eller lokalt via exempelvis ett USB-minne. Ghostning erbjuder därmed enkel distribution av både operativsystem och tillhörande programvara. 4.1.5 VoIP IP-telefoni, eller såkallad VoIP(Voice over IP), innebär att man i datornätverk via protokollet IP kan ringa och ha röstsamtal. Eftersom trafiken går igenom Internet så blir det i princip gratis, förutsatt att man har en internetuppkoppling. Dock gör det att vanliga problem angående Internet som förlorade eller fördröjning av paket kan påverka samtalen negativt. Specialtillverkade telefonväxlar, exempelvis Cisco Unified CallManager Express (CME), kan användas för att koppla ihop IPtelefonsystem på kontor från hela världen och ringa mellan dessa. 8
Teori 4.2 Core Coregruppen fokuserade på teknologi som ger redundans och säkerhet innom stamnätverket, följande stycken kommer ge en grundläggande genomgång av VPN, HSRP samt brandväggar. 4.2.1 VPN Virtual Private Network (VPN) är en teknik som används för att skapa säkra förbindelser över Internet, dessa kallas VPN-tunnlar. Detta innebär att data som skickas genom en tunnel kapslas in och krypteras och kan inte dekrypteras utan krypteringsnycklarna. Denna teknik går även använda för att dölja sin verkliga Ip-adress om man exempelvis vill kunna surfa anonymt på Internet. Någon som observerar en VPN tunnel utifrån kan enbart se den adress som tunneln terminerar på. Det finns flera olika typer av VPN tunnlar som kan användas. Site-to-Site VPN innebär att en VPNtunnel skapas mellan två fasta punkter, dessa punkter konfigureras med identiska autentiserings villkor. Tidigare var det vanligt att företag hyrde dedikerade fasta linor av en ISP. Fördelen med detta är att man får mycket stabila och säkra anslutningar. Den stora nackdelen är dock att kostnaden blir mycket hög och eskalerar ju längre avstånd som skiljer platserna åt. Fördelen med detta i jämförelse med Remote VPN är att tunneln alltid är uppe, dock kan den gå ner i vila efter en stunds inaktivitet. Användarna på det lokala nätverket behöver heller inte ansluta via en VPN klient eftersom all trafik som skall gå över Internet per automatik går över VPN-tunneln. Remote VPN fungerar på ett liknande sätt som Site-to-Site VPN med den skillnaden att VPN-tunneln inte upprättas mellan två fasta punkter. Istället kan en användare på resande fot upprätta en tunnel med hjälp av en VPN klient på sin laptop. Denna klient ansluter sedan mot den fasta punkten på företaget. 4.2.2 Brandvägg En brandvägg har som funktion att skydda nätverk genom att bara släppa igenom behörig trafik den kontrollerar och inspekterar trafiken mellan olika nätverk, oftast ett internt nätverk och internet. Brandväggen bestämmer om trafiken är behörig eller inte genom att använda sig av regler som avgör om trafiken får passera eller om den ska blockeras. Reglerna brukar vara baserade på IP adress, protokoll, portnummer och applikation. Det finns olika typer av brandväggar, en hårdvarubrandvägg är en egen enhet som är specialiserad för att agera som brandvägg och en mjukvarubrandväg är ett program som installeras på en klient för att ge brandväggsfunktionalitet. 4.2.3 HSRP Hot Standby Router Protocol (HSRP) är ett Cisco proprietärt redundans protokoll som används för att skapa en feltolerant default-gateway. När HSRP används så samverkar minst två routrar för att ge illusionen till en klient inom ett LAN att det endast finns en default-gateway. Detta görs genom att en virtuell router presenteras till klienten, de faktiska ip adresserna förblir dolda. Inom denna grupp av routrar utses en router som ansvarig för att vidarebefordra de paket som en klient skickar till den virtuella routern. Denna kallas för den aktiva routern, inom gruppen utses också en standby router som tar över ifall den aktiva routern skulle gå ner. Det är endast mellan den aktiva och standby routern som HSRP meddelande skickas periodiskt för att undvika onödig trafik. När standby routern tar över får den rollen som den aktiva routern och en ny standby router måste utses från gruppen av routrar. 9
Teori 4.3 Services Servicegruppen fokuserade på de olika nätverkstjänster som nätverket byggdes för att leverera samt övervakning av dessa. Följande rubriker kommer ge en grundläggande genomgång av Cacti, AD, MySQL, DNS, DHCP, OLA och SPORTident. 4.3.1 Cacti Cacti är ett webbaserat övervakningsprogram med öppen källkod som bygger på RRDtool. Programmet kan övervaka dator- och nätverkssystem, både enheter och dess tjänster. Exempelvis kan man övervaka belastning på CPU eller bandbredd. Cacti använder sig av RRDtools egenskaper att generera grafer, och man kan använda sig av olika templates för att lägga till nya sorters grafer. Det finns ett officiellt forum där man kan ladda upp och hämta färdiga templates och skript som andra har gjort och använda sig av. Exempel på graf, här trafik på switchportar. 4.3.2 Active Directory AD (Active Directory) är Microsofts katalogtjänst. Tjänsten är tätt sammanbunden med och behöver Microsofts DNS-tjänst för att fungera. Tanken bakom AD är, förutom att hantera användare och datorer, att fungera som en auktoritet där applikationer och tjänster kan autentiseras mot en central punkt. Det centraliserade sättet att administrera domäner förenklar hanteringen av information om användare då man bara behöver ändra användardata på en plats istället för i flera olika applikationer. Alla användare, skrivare, datorer etc. delas upp i en hierarkisk trädstruktur, i så kallade Organizational Units. Med hjälp av GPO (Group Policy Object) tilldelas grupperna olika rättigheter till grupper av användare, datorer etc. Det samlade resultatet av användarens och datorns rättigheter avgör vilka program, skrivare etc. som får användas. För att en användare ska kunna använda valfri 10
Teori dator i domänen (med sina egna inställningar) används Roaming profiles och hemkataloger sparade på domänkontrollanten allternativt på en separat filserver. 4.3.3 MySQL MySQL är en relationsdatabasserver utvecklad i enlighet med Open Source-ideologin. Via uppköp så ingår MySQL nu under Oracles vingar. De största skillnaderna mellan MySQL och andra relationsdatabasservrar är själva databasmotorerna, samt att de implementerar frågespråket SQL (Structured Query Language) på lite olika sätt. MySQL har stöd för asynkron replikering. Replikering sätts upp med Master-Slave-relationer. För att få till en så kallad Master-Masterrelation sätts två relationer upp, där Server1 är Slave till Server2 samt Server2 är Slave till Server1. 4.3.4 OLA och SPORTident OLA är Svenska Orienteringsförbundets tävlingsadministrativa system. OLA är utvecklat i JAVA och bygger på en server/klient-lösning. Klienterna ansluter till Servern, som i sin tur kollar upp i databasen. OLA lagrar sin information i en databas. OLA-servern har en inbyggd databasmotor, som kan användas för mindre evangemang. För större evangemang kan man använda en extern databasmotor, exempelvis MySQL. Klienten går smidigt att starta upp i en webbläsare. För tidtagning används SPORTident vilket är ett system där varje löpare har ett RFID-chip. Chipet stämplas mot basenheter, där det lagras information om stämplingen både på basenhet och chip. Systemet använder en Masterenhet för att när den tävlande gått i mål läsa in total tid samt mellantider till det tävlingsadministrativa programmet. 4.3.5 DNS Datorer använder IP-addresser för att kommunicera med varandra. För att underlätta för användaren och ge en abstrakt adressering av datorer/servrar används domännamn. DNS (Domain Name System) håller koll på kopplingen mellan domännamn och ip-address. Med hjälp av en DNS-server kan man både ta reda på IP-adress för ett speciellt domännamn, likaväl som man utifrån en IPadress kan ta reda på ett domännamn. DNS-systemet bygger på hierarkisk delegering av så kallade zoner. Det vill säga att en publik DNSserver bara kan bygga vidare på den zon den har tillstånd för. Domännamnet är uppdelat med punkter, för att härledas upp till rooten. Exempelvis: oringen.se. När ett domännamn ska översättas till en ip-address så går en fråga först till en rootserver, som skickar vidare till se:s namnserver. se:s namnserver skickar i sin tur vidare till en tredje namnserver, och så vidare tills en namnserver som har koll levererar ett svar. Svaret sparas sedan i en cache för att inte behöva göra om proceduren vid senare förfrågningar om domännamnet. 11
Teori 4.3.6 DHCP DHCP är en metod för att tilldela datorer den nätverksinformation som behövs för att fungera i ett nätverk. Exempel på viktiga uppgifter är IP-adress, IP-nätmask, DNS-server, Gateway samt utlåningstid. En DHCP-server delar ut denna information och lagrar vilken dator som har vilken ipadress med datorns unika MAC-adress. En klient går igenom fyra steg när den hämtar en IP-adress från en server. DHCP discovery - Förfrågan skickas, vilket medför att dhcp-servrar för nätet får reda på att en klient är ute efter en ip-adress. Detta Broadcastas. DHCP offer - Servern skickar ett erbjudande till klienten. Detta skickas via unicast. DHCP request - Klienten skickar en begäran via broadcast för att acceptera ett av de erbjudanden som den tagit emot. Klienten brukar ta det första erbjudandet. DHCP acknowledgment - dhcp-servern skickar en bekräftelse via unicast på att klienten får den ipadress som erbjudits. När utlåningstiden löper mot sitt slut skickar klienten en ny request för att få behålla ip-adressen. 4.3.7 NTP Network Time Protocol (NTP) är ett protokoll som används för att synkronisera klockan för datorer och utrustning i ett nätverk. NTP har utvecklats från andra protokoll som Daytime, ICMP timestamp och det äldre Time protocol (TimeP). NTP använder UDP port 123. Exakt tid i ett nätverk är viktigt, även skillnader på små bråkdelar av en sekund kan orsaka problem. I grund och botten består NTP av en klient som frågar en server efter nuvarande tid och använder det för att ställa in sin egen klocka. NTP servrar använder en hierarki baserad på stratum. De pålitligaste enheterna har stratum 0 och består av atomklockor, GPS-klockor och radioklockor. De servar som är anslutna till en stratum 0 enhet blir stratum 1 i hierarkin och så vidare. 12
Planering och Genomförande 5 Planering och genomförande Valet att behålla föregående års ansvarsfördelning gjordes då den var både logisk och funktionell. Arbetet delades såldedes in i följande tre grupper. Access Bestående av: Carl Folkesson (JTH) Daniel johansson (JTH) Fredrik Ankarstrand (JTH) Accessgruppen anvarade för switcharna ut mot slutanvändare, felsökning av datorer, kontaktpersoner mot slutanvändare samt installation av klientdatorer. Core Bestående av: Niklas Bogeholm (Coordinator, JTH) Niklas Eriksson (JTH) Frank Svensson (JTH) Coregruppen ansvarade för uppbyggnad och drift av stamnätet, samtliga VPN tunnlar mellan de olika platserna och konfiguration av Brandväggen. Services Bestående av: Anders Richter (JTH) Fredrik Hulth (JTH) Servicegruppen ansvarade för installation och drift av de olika nätverkstjänsterna viktigast bland dessa var OLA och medföljande tävlingsdatabas. 13
Planering och Genomförande 5.1 Access Samtliga Switchar på accessnivå är redundant kopplade med länkar till två olika Distributionsswitchar. Om en faktisk switch skulla fallera så finns det switchar i reserv. Dessa är konfigurerade efter en generellt skriven mall så att enbart portar med någon speciell enhet, till exempel en skrivare eller AP behöver konfigureras. Även detta finns det mallar för. 5.1.1 Switchar Under hela labbperioden användes switchar från labbsalarna, för att sedan ersättas nästan helt av beställda switchar från Cisco. Dessa bestod av 24-portars Cisco 2960 med PoE (Power over Ethernet) för att kunna förse accesspunkterna med ström. Samtliga beställda switchar hade även dual-purpose portar som antingen kan användas för gigabit ethernet eller anslutas mot fiber via en SFP. Något som ansågs som mycket användbart då en del accesswitchar var belägna på långt avstånd från motsvarande distributionsswitchar. Eftersom Accesslagret i planeringsstadiet var svårt att föreställa sig helt hur det skulle se ut, så riktade vi in oss på att skapa mallar för olika typer av portar, t.ex: Public Internet Accesspoints Trunkar WLAN Controllers IP-telefoner Dessutom kunde vi skapa en grundläggande konfigurering som i vilken fall som helst skulle behöva appliceras på samtliga switchar. 5.1.2 Trådlöst lan Trådlöst nätverk är inplanerat för användning av pressen, deltagare och för mässan. Det kommer att finnas accesspunkter på de platser där pressen kommer att hålla till och på mässområdet i staden. Dessa kommer att vara WPA2 skyddade med en utdelad nyckel. Nyckeln kommer att vara utdelad endast till dem som skall ha behörighet till dessa trådlösa nät. Eftersom alla i dessa wlan kommer att ha samma behörighet så blir det lättare att administrerat med en utdelad nyckel. Det kommer att finnas ett oskyddat nätverk i staden där deltagare kan koppla upp sig för att få tillgång till internet där all icke web trafik kommer att blockeras. Det kommer även att finnas ett trådlöst nätverk överallt där det kommer finnas accesspunkter som kommer ha ett dolt SSID och en privatnyckel som kommer användas av oss för att kunna komma åt vårt management nät trådlöst. Alla trådlösa nätverk och accesspunkter kommer att styras från en Wireless Lan Controller (WLC) som gör att allt går att administrera från en centralpunkt. En sekundär WLC kommer att ta över alla de trådlösa nätverken och inställningar ifall den primära skulle gå ned. Dessa kommer vara utplacerade på olika ställen för att minska risken att båda går ner samtidigt. Det kommer även att finnas en WLC som sköter de trådlösa på arenorna, den kommer att flyttas runt och endast köras på den arenan som kommer att vara aktiv. Detta för att inte någon onödig wlan trafik skall behövas gå över länken in till staden. Accesspunkterna kommer att få strömförsörjning genom Power over Ethernet (PoE) om det inte finns en strömkontakt intill den. 14
Planering och Genomförande Illustration av hur WLC och accesspunkterna kan vara kopplade i nätverk. 5.1.3 Voip Call manager express (CME) kommer att köras på en Cisco 2811 router som kommer användas för IP-telefonin. Routern kommer endast att agera som en server för telefonerna, dessa kommer att hämta konfigurationen därifrån när de kopplas in i nätverket. Telefonerna fungerar inte utan en CME server där grundinställningar, telefonnummer och alias sparas. Telefonin kommer att ha ett eget vlan och då även ett eget DHCP scope. I DHCP scope sätts option 150 (TFTP-server) till CME serverns IP-adress. Detta för att telefonerna då vet vart de skall hämta inställningar ifrån. Telefonerna använder sig även av CME servern när ett samtal skall kopplas upp. Men när samtal är uppkopplat så kommer trafiken gå direkt mellan telefonerna och servern är då inte inblandad. Telefonerna som kommer att användas är Cisco 7940 IP-telefoner, vi planerar att ta med oss 8 stycken. Telefonerna planeras att endast användas av oss under eventet så vi inte behöver använda oss av mobiltelefoni. De kommer att placeras på lämpliga ställen där antingen vi eller annan personal kommer att befinna sig. På så sätt kan vi nå varandra enkelt, snabb och kostnadsfritt ifall något problem uppstår 15
Planering och Genomförande 5.1.4 Ghostning Valet av programvara för ghostningen var inte självklar. Automatiserad ghostning var ingenting som gruppen hade jobbat speciellt mycket med, varpå vi testade 3 olika lösningar för att se vilken som var bäst lämpad. Gemensamt för de tre lösningarna var att man kombinerade dom tillsammans med verktyget Sysprep. Med tanke på avsaknad av volymlicensen vi skulle få av Oringen, fick vi endast laborera så att allt skulle gå så smärtfritt som möjligt när vi väl fick lägga vantarna på volymlicensen. En ren XP-maskin installerades och uppdaterades fullt ut. Sedan installerades alla programvaror som hade önskats av Oringen. De krav dom hade var: Java OpenOffice PDF-läsare F-Secure Client Security Eventuella skrivardrivrutiner Till detta valde vi att ersätta Internet Explorer med Mozilla Firefox, som vi tycker är ett bättre alternativ som webbläsare. När även dessa programvaror var uppdaterade, stängde vi av ev. Automatiska uppdateringar på alla program samt windows update. Detta för att vi inte ville ha onödiga problem med frågande personal eller överdriven bandbreddskonsumtion om det skulle börja dyka upp rutor angående updates. En Sysprep-mapp skapades på c:\ där 3 filer kopierades ur filen deploy.cab. Filen återfinns på tillhörande XP-skiva. Setupmgr.exe körs först där man väljer de olika inställningarna som måste fyllas i vid en installation. Här fyller man i t.ex. serialkey, om man vill gå med i en domän och vilka språkinställningar man vill ha. Den enda rutan vi lämnar blank är Computer Name, som vi vill fylla i manuellt vid Deployment. Detta gör vi för att kunna sätta en matchande klisterlapp på datorn för identifikation under eventet. För att slutföra sysprep kör man filen Sysprep.exe och kryssar i Mini-setup, samt Detect non- PlugandPlay Devices och klickar på reseal. Sysprep körs och datorn stängs av. Nu är datorn redo för att PXE-boota in i valfritt ghostprogram och köra en Capture. 5.1.4.1 Windows Deployment Service WDS är en tjänst som följer med Windows Server, och vi valde att arbeta med Windows Server 2008. WDS är beroende av ett fungerande AD, DNS och en DHCP-server. Man laddar in filen boot.wim från en Windows Vista Business-skiva. Anledningen till detta är att Vista är den äldsta releasen av Longhorn, och den enda som stödjer ghostning av XP. Av filen skapar man en Capturesession där man kan göra en image av den Syspreppade datorn. Efter detta lägger man in Imagen som en ny session där klienterna kan boota in och få imagen kopierad till hårddisken. Vi stötte dock på problem här, då WDS klagade på att vi inte hade rätt nätverksdrivrutiner, trots att vi kunde skapa en capture utan några som helst problem. Själva Capture-sekvensen tog också väldigt lång tid. Våran Sysprep tog ungefär 4 timmar att kopieras. Resurserna som krävs för att genomföra full ghost med WDS system är ganska stora, eftersom Windows Server 2008 har höga systemkrav. 16
Planering och Genomförande 5.1.4.2 Clonezilla Clonezilla får anses lite som en outsider, då det är ett helt gratis alternativ. Programmet installeras som en tjänst på valfri Linux-distribution och använder DRBL och DHCP. Systemet är bra mycket mindre krävande än övriga alternativ då det flöt på fint med endast 1024MB RAM. En full installation inklusive installation av Operativsystemet gjordes på under en timme beroende på hastigheten på Internetuppkopplingen. Vid första försöket med Clonezilla hade vi stora problem, som vi till slut kom fram till berodde på att det hade lite kompatibilitetsproblem med den nya distributionen av Ubuntu. Ubuntu har även en LTS (Long Time Support) version som släpptes i April 2010. Denna fungerade mycket bättre. Att skapa en image av en Sysprep tog inte mer än 10-15 minuter, och utskjutning av densamma ungefär 30-40 minuter, beroende på hur många klienter vi anslöt till servern under testandet. Skillnaden mellan 1 och 6 klienter var bara några minuter. Valet av ghosttjänst var i detta läget inte svårt och valet landade på clonezilla. Det är överlägset den bästa lösningen vi testade, och dessutom gratis. Eftersom vi antagligen kommer färdas till närliggande skolor under eventet och utföra ghostningen har vi begränsat med tid på oss för att utföra denna. Vi vill därför effektivisera arbetet så långt som möjligt och valde att installera 3 upplagor av deploymaskiner. Det kommer finnas en image för varje Laptop-modell. Pga det låga systemkravet fungerar det utmärkt att köra tjänsten på medhavda laptops. Varje server skjuter då ut imagen till varsin fullsatt switch med klienter. 17
Planering och Genomförande 5.2 Core Stamnätet planerades primärt med redundans och säkerhet i åtankte om någon enhet skulle fallera så finns det i så stor utsträckning som möjligt en backup enhet som tar över funktionen, det finns även switchar i reserv så den fallerade enheten snabbt går att byta ut. 5.2.1 Nätverksplan Både i staden och på arenan finns redundant kopplade distribution switchar som delar på default gateway för de olika vlanen via HSRP. Dessa distribution switchar är i sin tur kopplade till en core switch i form av Cisco 6500 på vardera sida av staden och arenan. Dessa routar trafik som antingen skall ut på internet eller till arenan/staden genom en ASA 5520 brandvägg. Väl hos ASA:n natas antingen trafiken ut mot internet eller går över en VPN-tunnel om trafiken skall till de interna subnäten på andra sidan av staden/arenan. Routingprotokollet EIGRP används mellan distribution och Core switcharna. Se nedanstående bilder för Nätverkskarta över Staden, Arenorna är uppbyggda enligt snarlik modell men kommer antagligen skilja sig lite beroende på avstånd. 18
Planering och Genomförande Serverhus Legend L2 Ethernet L3 L2 Fiber L3 Fiber Staden-Press-A1 Staden-Press-A2 Staden-Press-A3 Staden-Expedition-A1 Mässan Staden-Serverhus-D2 Staden-Serverhus-D1 Staden-Core-1 Staden-Stugan-A1 Stugan VPN mot Arena Staden- ASA-1 Staden-Server-A1 Staden- CME1 Internet Mässan Staden- WLC2 Staden-Radio-A1 Radio Måltidstorg Serverhus Staden-Sport-A1 Sportförsäljning Staden-Massan-D1 Staden-Massan-D2 Staden-WLC1 Staden-Massan-A1 19
Planering och Genomförande 5.2.2 Vlan och IP-planering För enkelhetens skull så valde gruppen att köra separata subnät på Staden och Arenorna. Subnät med motsvarande syfte gavs samma vlan numrering för överskådlighet då allt ändå routas av innan vpn tunneln. Se nedanstående tabeller över Vlan och länknät. Staden Vlanid Description IP-Nät DHCP-server 1 DHCP-server 2 10 Management 10.10.0.0/16 10.10.0.0-10.10.10.255 10.20.11.0-10.20.15.255 20 Public 10.20.0.0/16 10.20.0.0-10.20.10.255 10.20.11.0-10.20.15.255 30 Sjukvård 10.30.0.0/16 10.30.0.0-10.30.10.255 10.30.11.0-10.30.15.255 40 Ola 10.40.0.0/16 10.40.0.0-10.40.10.255 10.40.11.0-10.40.15.255 50 Press 10.50.0.0/16 10.50.0.0-10.50.10.255 10.50.11.0-10.50.15.255 60 Mässan 10.60.0.0/16 10.60.0.0-10.40.10.255 10.60.11.0-10.60.15.255 100 Server 10.100.0.0/16 10.110.0.0-10.110.11.0-110 Voip 10.110.0.0/16 140 AP-Management 10.140.0.0/16 150 Sport(publikt) 10.150.0.0/16 160 Radio 10.160.0.0/16 170 TV 10.170.0.0/16 180 Printer 10.180.0.0/16 10.110.10.255 10.140.0.0-10.140.10.255 Arena 10.110.15.255 10.140.11.0-10.140.15.255 Vlanid Description IP-Nät DHCP-server 1 DHCP-server 2 192.168.10.1-192.168.10.121-10 Management 192.168.10.0/24 192.168.10.120 192.168.10.254 20 Public 192.168.16.0/21 192.168.16.1-192.168.19.255 192.168.20.0-192.168.23.254 30 Sjukvård 192.168.30.0/24 192.168.30.1-192.168.30.120 192.168.30.121-192.168.30.254 40 Ola 192.168.40.0/23 192.168.40.1-192.168.40.255 192.168.41.0-192.168.41.254 50 Press 192.168.50.0/23 192.168.50.1-192.168.50.255 192.168.51.0-192.168.51.254 60 Mässan 192.168.60.0/23 192.168.60.1-192.168.60.255 192.168.61.0-192.168.61.254 100 Server 192.168.100.0/24 192.168.110.1-110 Voip 192.168.110.0/24 192.168.110.120 Ap- 192.168.140.1-140 Management 192.168.140.0/24 192.168.140.120 192.168.110.121-192.168.110.254 192.168.140.121-192.168.140.254 160 Radio 192.168.160.0/24 170 TV 192.168.170.0/24 180 Printer 192.168.180.0/24 20
Planering och Genomförande Länknät Subnät Punkt1 Punkt2 10.120.0.0 /30 10.120.0.1 Staden-Core-1 10.120.0.2 Staden-Asa-1 10.120.0.4 /30 10.120.0.5 Staden-Core-1 10.120.0.6 Staden-Massan-D1 10.120.0.8 /30 10.120.0.9 Staden-Core-1 10.120.0.10 Staden-Massan-D2 10.120.0.12/30 10.120.0.13 Staden-Core-1 10.120.0.14 Staden-Serverhus-D1 10.120.0.16/30 10.120.0.17 Staden-Core-1 10.120.0.18 Staden-Serverhus-D2 10.120.0.20/30 10.120.0.21 Staden-Serverhus-D1 10.120.0.22 Staden-Serverhus-D2 10.120.0.24/30 10.120.0.25 Staden-Serverhus-D1 10.120.0.26 Staden-Massan-D1 10.120.0.28 /30 10.120.0.29 Staden-Serverhus-D1 10.120.0.30 Staden-Massan-D2 10.120.0.32 /30 10.120.0.33 Staden-Serverhus-D2 10.120.0.34 Staden-Massan-D1 10.120.0.36 /30 10.120.0.37 Staden-Serverhus-D2 10.120.0.38 Staden-Massan-D2 10.120.0.40 /30 10.120.0.41 Staden-Massan-D1 10.120.0.42 Staden-Massan-D2 5.2.3 Säkerhetslösning Vi har här valt att implementera två fasta Site-to-Site VPN-tunnlar, en mellan staden och arenan och en mellan staden och JTH. Detta för att det fanns ett önskemål från O-ringen att det skulle finnas en VPN-tunnel mellan staden och arenan och även för att vi vill kunna replikera trafik till servrar på JTH. För detta ändamål kommer vi att använda två ASA 5520 brandväggsenheter under O-ringen samt en ASA 5510 på JTH. Dessa används främst för att upprätta VPN-tunnlar men kommer även användas för paket inspektion/restriktion och NAT. Det kommer också finnas en extra ASA 5510 under O-ringen ifall något skulle hända med ordinarie enheter. Övrig utrustning såsom routrar och switchar kommer konfigureras med säkra lösenord och övrig grundläggande säkerhet. Vi kommer dock inte överdriva dessa aspekter och säkra upp utrustningen mer än nödvändigt. 21
Planering och Genomförande 5.3 Services Precis som övriga grupper arbetade Servicegruppen med fokus på redundans de flesta servrarna är installerade i två exemplar en primär och en sekundär. I en del fall ligger den sekundära servern på andra sidan VPN tunneln men detta ansågs acceptabelt då det skulle kräva att både den primära servern går ner samt att VPN-tunneln går ner samtidigt för att problem skall uppstå. 5.3.1 Serverplan Staden Publik DNS Primär Dhcp, AD och intern DNS OLA/slave databasserver OLA/slave databasserver Övervakning och AD Arenan JTH OLA/primär masterdatabasserver OLA/hot standby masterdatabasserver Sekundär Dhcp AD och intern DNS Slave databasserver O-ringen online Här är vår tanke att skapa redundans. Även om WAN-länken skulle gå ner har vi funktion på bägge sidor av arenan/staden. Vi har även redundans om en server skulle gå ner på arenan eller i staden. I ett sådant fall når man servrarna på andra sidan WAN-länken. De två databas servrarna som finns på arenan är tänkt att använda master-master replikering. Datan kommer sedan att replikeras till en slave databas-server i staden, denna kommer replikera vidare till ytterligare en databas-server och till oringenonline på JTH. Vi använder oss av VmWare ESXi på samtliga maskiner utom den primära masterdatabas-servern på arenan. Detta för att det är den servern som kommer belastas hårdast. Samtliga servrar kör operativsystemet Windows Server 2008 r2. 22
Planering och Genomförande 5.3.2 Active Directory Vi har valt att ha tre DC (domänkontrollanter) för domänen oringen.local. Detta för att skapa redundans då det är viktigt att alla berörda har möjlighet att logga in på datorer och använda OLA. En placeras på arenan och 2 stycken i staden. Detta för att det alltid skall finnas en DC även om WAN-länken skulle sluta att fungera. Anledningen till att vi använder oss av 2 stycken i staden är att Arenan plockas ner efter varje tävling. Alla DC använder microsofts egna DNS. DNS records, användare och Group Policys kommer replikeras genom AD. Under eventet kommer vi huvudsakligen använda oss av dessa användarkonton: Administrator OLA Alla funktionärer kommer logga in med ett och samma konto och alla i O-ringengruppen kommer att logga in som Administrator när konfigurering behövs. Detta gör vi för att förhindra att funktionärer ändrar inställningar och skapar oreda i datorerna. 23
Planering och Genomförande 5.3.3 DHCP Windows DHCP tjänst används för dynamisk tilldelning av IP-adresser. Vi har valt att använda två DHCP servrar för att skapa redundans. Den ena placeras i staden och den andra i arenan. Dessa använder sig av split-scope. Detta innebär att DHCP servrarna delar ut olika scopes ur samma ip nät för att undvika ip konflikter. Skulle den ena servern gå ner kan klienterna fortfarande få ip adresser från den andra. Denna uppdelning kan ses i tabellen nedan: DHCP-server Staden: Vlan-id Namn: Nät: Scope: 10 Management Staden 10.10.0.0 /16 10.10.0.1-10.10.10.255 20 Public Staden 10.20.0.0 /16 10.20.0.1-10.20.10.255 30 Sjukvård Staden 10.30.0.0 /16 10.30.0.1-10.30.10.255 40 Ola Staden 10.40.0.0 /16 10.40.0.1-10.40.10.255 50 Press Staden 10.50.0.0 /16 10.50.0.1-10.50.10.255 60 Mässan Staden 10.60.0.0 /16 10.60.0.1 10.60.10.255 110 Voip Staden 10.110.0.0 /16 10.110.0.1-10.110.10.255 140 AP-Management Staden 10.140.0.0 /16 10.140.0.1-10.140.10.255 10 Management Arenan 192.168.10.0 /24 192.168.10.1-192.168.10.120 20 Public Arenan 192.168.16.0 /21 192.168.16.1-192.168.19.255 30 Sjukvård Arenan 192.168.30.0 /24 192.168.30.1-192.168.30.120 40 Ola Arenan 192.168.40.0 /23 192.168.40.1-192.168.40.255 50 Press Arenan 192.168.50.0 /23 192.168.50.1 192.168.50.255 60 Mässan Arenan 192.168.60.0 /23 192.168.60.1 192.168.60.255 110 Voip Arenan 192.168.110.0 /24 192.168.110.1-192.168.110.120 140 AP-Management Arenan 192.168.140.0 /24 192.168.140.1-192.168.140.120 DCHP-server Arena: Vlan-id Namn: Nät: Scope: 10 Management Staden 10.10.0.0 /16 10.20.11.0-10.20.15.255 20 Public Staden 10.20.0.0 /16 10.20.11.0-10.20.15.255 30 Sjukvård Staden 10.30.0.0 /16 10.30.11.0-10.30.15.255 40 Ola Staden 10.40.0.0 /16 10.40.11.0-10.40.15.255 50 Press Staden 10.50.0.0 /16 10.50.11.0-10.50.15.255 60 Mässan Staden 10.60.0.0 /16 10.60.11.0-10.60.15.255 110 Voip Staden 10.110.0.0 /16 10.110.11.0-10.110.15.255 140 AP-Management Staden 10.140.0.0 /16 10.140.11.0-10.140.15.255 10 Management Arenan 192.168.10.0 /24 192.168.10.121-192.168.10.254 20 Public Arenan 192.168.16.0 /21 192.168.20.0-192.168.23.254 30 Sjukvård Arenan 192.168.30.0 /24 192.168.30.121-192.168.30.254 40 Ola Arenan 192.168.40.0 /23 192.168.41.0-192.168.41.254 50 Press Arenan 192.168.50.0 /23 192.168.51.0-192.168.51.254 60 Mässan Arenan 192.168.60.0 /23 192.168.61.0-192.168.61.254 110 Voip Arenan 192.168.110.0 /24 192.168.110.121-192.168.110.254 140 AP-Management Arenan 192.168.140.0 /24 192.168.140.121-192.168.140.254 24
Planering och Genomförande För att IP-telefonin och acesspunkterna ska fungera har option 150 med ip-adressen till IPtelefonernas tftp-server lagts till i Voip-scopen och option 43 med ip-adressen till accesspunkternas WLAN-controllers lagts till i AP-Management-scopen. 5.3.4 OLA + Mysql ARENAN STADEN JTH Tvåvägsreplikering MySQL Envägsreplikering MySQL/OLA MySQL/OLA MySQL/OLA O-ringen Online Envägsreplikering Envägsreplikering MySQL/OLA Vi kommer att använda fem databasservrar, varav två placeras på arenan. Dessa kommer replikera som master-master, den ena kommer att vara i hot-standby läge. OLA servrarna placeras på samma maskiner som MySQL. I första hand kommer de att skriva till en av dem, den andra sätts i read-only läge för att undvika kollisioner och korrupt data som kan inträffa om någon av misstag skulle skriva till mastern i hot-standby läget. I staden konfigureras en databas server som slave till den primära Mastern ute på arenan. För att skapa redundans replikerar denna server till ytterligare en slave i staden. Denna har i sin tur en slave som är placerad på JTH. Backup av databasen kommer att tas på den primära MySQL-servern med hjälp av ett script som körs en gång var 15 minut. För att spara diskutrymme kommer backupen att komprimeras med det fria programmet 7zip. 25
Planering och Genomförande 5.3.5 Övervakning Programmet Cacti kommer att användas för nätverksövervakning via protokollet SNMP. Detta valdes för att det är ett freeware program som även användes av förra årets grupp med lyckat resultat. Detta har installerats på en Windows 2008 R2 server med de senaste uppdateringarna. Det som testats att övervaka på nätverksutrustningen är portstatus, trafikflödet, temperatur, processorbelastning och minneshanteringen. Det har även testats övervakning på samtliga servrarna samt diskutrymmet. Detta kräver att all utrustning har SNMP aktiverat då informationen till övervakningsprogrammet hämtas via SNMP protokollet. Cacti har ställs in för att hämta all information som valts en gång i minuten för att sedan spara det i en SQL databas som ligger lokalt på servern. Från databasen kan man sedan hämta informationen och skapa grafer för till exempel trafikflödet på någon port. Servern använder IIS (Internet Information Services) som används för att komma åt Cacti webbgränsnit via http. IIS används även för att kunna skicka mail (SMTP) till en vald adress. Så Cacti kan generar alarmmail som skickas till en eller flera mailadressers ifall något skulle bli okontaktbart eller ifall någon parameter inte uppfylls i nätverket. Eftersom att vi har tillgång till mail i telefonen så kommer mailet att kunna ses omedelbart. Alarmmailen genereras med hjälp av pluginen Thold till Cacti där olika parametra kan ställas in, till exempel ifall en host går ner eller om belastningen överstiger en viss procent på någon enhet. 26
Resultat 6 Resultat Vi hade relativt väl genomtänkta planer innan vi färdades till mohed för själva eventet, men som följande kapitel kommer visa så ligger det något I det gamla strategiska talesättet. No Battleplan ever survives contact with the enemy. 6.1 Services 6.1.1 Övervakning Cacti användes för övervakningen av all nätverksutrustningen. All nätverksutrustning lades till i Cacti för att kunna se deras aktuella status. Vi hade 1 minuts fördröjning på övervakningen då Cacti pollade utrustningen en gång i minuten. Detta minskade trafiken därifrån men hade kunnat vara ännu lägre då vårt nät inte var i närheten av överbelastat. Vi övervakade även det trådlösa nätverket genom WLAN-kontrollerna för att kunna se hur belastat det var. Vår ISP länk övervakades också med stående ping utåt och bandbreddsflöde. Samtliga serverar övervakades också. Se Bilaga 1 för diverse grafer över bandbreddsanvändningen. Vi hade igång mail utskick till en gemensam mail som vi hade inlagd i telefonerna för att genast få reda på om något gick ner eller upp. Detta gjorde att ingen behövde sitta och hålla koll på en skärm med all utrustnings status hela tiden. Ingen av våra länkar blev överbelastade och det mesta fungerade bra, vi kunde snabbt och enkelt få reda på ifall någon switch eller annan utrustning blev okontaktbar. De flesta fallen när någon gick ner berodde på att någon flyttade på utrustning eller råka dra ut fel kabel. 6.1.2 Active Directory Det problem som uppstod med användandet av Active Directory var att OLA-klienten behövde skrivrättigheter till All Users, detta var inte något som vi hade tagit hänsyn till i förberedelserna, vilket resulterade i att vi till alla OLA-klientdatorer som arbetade delade ut användarnamn och lösenord till lokaladmin. Det gjorde att AD till viss del förlorade sin nytta. Dessutom hade vi problem med att skapa ett konto med webb i kioskläge för låst åtkomst mot OringenOnline. 6.1.3 OLA och MySQL Under O-ringen användes databasservrar stående i Serverhuset, på Arenan och på JTH. Under tävlingsdagen var Arenan den primära databasservern och övrig tid Serverhuset. Under första etappen upptäcktes att OringenOnline inte uppdaterades som beräknat, vilket visade sig bero på att replikeringen mellan Serverhuset och JTH inte fungerade. Eftersom replikeringen inte går att få igång under användning av databasen var vi tvungna att uppdatera JTH manuellt under första dagen genom att med jämna mellanrum ta dumpar av databasen i Serverhuset och lägga in i JTH. Under natten mellan första och andra tävlingsdagen gjordes stora försök att få igång replikeringen, dock utan lyckat resultat. Däremot skapades ett script som var tredje minut automatiskt gjorde en dump av databasen i Severhuset och lade in den i JTH-servern. Mellan andra och tredje tävlingsdagen var en vilodag, och under denna dag löstes problemet med replikeringen. Det visade sig bero på två skilda saker, dels startade replikeringen från fel position i loggfilen, något som fungerat utan problem vid all annan replikering, dels hade vi missat att lägga in alla databaser i JTH-serven, där låg bara oringen2011-databasen, den enda som webbservern använde sig av. I Serverhuset fanns 27
Resultat även andra databaser, bland annat en för mountainbike-orienteringen, som kördes parallellt med de andra tävlingarna. Så fort en ändring gjordes i någon av dessa databaser gick replikeringen mot JTH ner, lösningen blev att lägga in alla databaserna även i JTH-serven, trots att den egentligen bara hade behov av oringen2011-databasen. Enda gången som OLA gick segt var en sekvens under etapp 5, jaktstarten. Anledningen var att den primära databasservern på arenan plötslig blev överbelastad. Lätt panik utbröt, då alla inläsningsstationer slutade att fungera och det väldigt snabbt blev köer där. Nya OLA-servrar startades på nya portar och relativt omgående kom inläsningsstationerna igång igen, men speakern, som är den som belastar databasen hårdast, tyckte det gick väldigt segt. Ytterligare en OLA-server startades på en ny port åt dem, och det fungerade hjälpligt. Belastningen låg dock fortfarande på 100 % på databasserven. Felsökningen fortsatte, men eftersom tävlingen ändå flöt på var vi rädda för att göra allt för stora ingrepp. Efter ca en kvart gick plötsligt belastningen ner till en normal nivå igen. I efterhand kan man konstatera att den bästa lösningen förmodligen hade varit att direkt peka om alla OLA-servrar mot Serverhuset när det blev problem med Arena-servern. Men under den stress som rådde och med många trötta huvuden var det ingen som tänkte så långt. 6.1.4 OringenOnline OringenOnline fungerade felfritt sånär som på lite problem med installationen. Av någon anledning så användes varken NETWORKSERVICE, eller IUSR kontot för att skriva till den mapp som websidans loggar sparades i, detta ledde till försvårad felsökning och fick slutligen lösas genom att ge ALLUSERS skrivrättigheter till mappen i fråga då det började bli knappt om tid. Ett annat problem var att Default Document pekade fel vilket ledde till att sidan inte fungerade om man inte skrev in rätt dokument på adressraden i webläsaren manuellt. Dessa problem löstes dock innan tävlingens start. 6.2 Access 6.2.1 Ghost När vi kom fram till Söderhamn fick vi 3 olika datormodeller presenterade för oss, varav 2 av dessa hade vi redan färdiga images för. Vi använde oss av 2 stycken ghostswitchar för att distribuera ut ghosten till klienterna. Själva överföringen av ghosten gick väldigt smärtfritt, och ungefär 15-20 datorer kunde ghostas i taget utan att man märkte av någon prestandaförlust från servern. Anledningen till att vi använde oss av 2 switchar var att vi ville få 2 slutna miljöer att ghosta i, och att själva ghostningen tar stor fysisk plats, vilket gör att 2 switchar är att föredra så man kan dela upp sig i 2 olika rum. Dock fick vi stora problem när datorerna skulle ansluta till domänen, då klienterna klagade på att den lokala tiden inte stämde överrens med domänens. Det märkliga var att det ibland fungerade, och ibland inte. Lösningen hittade vi dock senare efter en stunds felsökning. När vi försökte synka tiden mellan sekundär DC och primär DC (NTP-servern), klagade systemet på att det var för stor tidsskillnad och att synkningen inte kunde gå igenom. Efter mycket lusläsning var problemet så enkelt som att tiden var helt korrekt, men datumet skiljde sig dock med en hel månad. Efter detta uppstod inte dessa problem. Varför det tidigare fungerade vid vissa tillfällen berodde helt enkelt på vilken DC som svarade på inloggningsförsöket. Vid ett senare tillfälle fick vi fler datorer att ghosta, denna gång stationära, vilket gjorde arbetet lite bökigare, eftersom man måste koppla in tangentbord och skärm för att PXE-boota. Här märktes också att ghosten blev riktigt seg om man försökte fylla switchen med klienter. Vid 24 klienter gick 28
Resultat det knappt framåt. Vi fick nöja oss med 12 klienter åt gången, och en omgång tog då ungefär 10 minuter. 6.2.2 Trådlösa nätverk I staden satte vi upp en primär och en sekundär WLC för att få redundans ifall någon av dem skulle fallera. Vi satte även upp 9 stycken accesspunkter på lämpliga ställen för att täcka O-ringen stadens område så bra som möjligt. Det fanns fyra olika WLAN i staden som låg i olika VLAN för att skilja dem åt. O-ringen Guest Helt öppet för alla deltagare för att koppla upp egna enheter och surfa. O-ringen Fair/exhibition Detta var skyddat med WPA2 och en utdelad nyckel som alla utställare på mässa fick använda. O-ringen Press Detta var också skyddat med WPA2 och en utdelad nyckel som pressen fick använda sig av. Technet Användes av oss i nätverksgruppen, skyddat med WPA2 och dolt SSID samt en nyckel som endast vi visste om. Detta för att vi skulle kunna koppla upp oss mot management vlanet överallt trådlöst. På arenan användes som i staden två WLC för att skapa redundans. Vi använde oss även bara av 2 accesspunkter som var placerad hos pressen, det var samma nyckel för pressen som det var i staden. Det var även tänkt att det skulle vara ett öppet WLAN på arenan, men vi satte inte upp det för att O- ringen personalen sa att det inte var behov av ett öppet nätverk på arenan. Därför blev det mindre accesspunkter på arenan en vad vi hade planerat. Det upplevdes inte vara några problem med WLAN:en förutom ett lite fel ute på arenan första dagen. Då lösenordet var felskrivet på WLC för pressen. Detta åtgärdades snabbt och enkelt på WLC. Högsta antal klienter på samma tidpunkt var 124 stycken i staden. 29
Resultat Högsta antal klienter på samma tidpunkt var 40 stycken på arenan. 6.2.3 IP-telefoni Vi hade planerat att ha en del IP-telefoner utplacerade på olika ställen där det fanns nätverksutrustning eller behov av snabb kommunikation. Det blev dock bara en telefon i serverrummet och en i serverbussen ute på arenan som användes mellan oss under tävlingarnas gång. Vi placera en i expeditionen också men den användes aldrig. Det var en väldigt bra lösning med IP-telefoni för oss, då några av oss hade dålig mottagning ute på arenorna och att vi inte behövde betala någon samtalskostnad för våra samtal mellan staden och arenan. 6.3 Core 6.3.1 Nätverket Initialt var nätverket designat med redundans i åtanke, detta för att undvika single point of failures till den grad det var möjligt. När vi väl var på plats i Mohed var dock verkligheten en annan. Trots att vi skickat ritningar över vår design till ansvariga, hade de endast dragit en kabel till de platser där våra switchar skulle placeras ut. Vi fick därför till viss del tänka om och valde att endast be om att ytterligare kablar skulle dras till de mest kritiska switcharna, som exempelvis resultat-switcharna i måltältet. HSRP var också konfigurerat med redundans och lastbalansering i åtanke. Dock kunde vi enbart ha en länk till de redundanta dist-switcharna från majoriteten av access-switcharna. Detta kunde skapa problem i samband med lastbalanseringen av HSRP. Vi löste detta genom att skapa en trunk mellan dist-switcharna. Till den sista etappen inne i Mohed fick vi med kort varsel veta att det inte skulle finnas någon WAN-länk. Detta skapade problem då vi planerat att använda oss av VPN-tunneln som vi gjort under tidigare etapper. Vi fick då plocka ner brandväggen i serverbussen och införliva arena-nätet under staden-nätet. Detta löste vi genom en länk mellan dist-switch i serverhuset och dist-switch serverbussen. Vi satte upp en trunk mellan dist-switch i serverhus och dist-switch i mässan. Mellan dist-switchen i mässan och serverbussen körde via en vanlig access-länk. För detta ändamål satte vi 30
Resultat upp en SVI på serverhusets dist-switch i VLAN 15, på dist-switchen i Mässan sattes VLAN 15 på en accessport för att koppla in mot serverbussen. Detta verkade fungera bra då vi sent på natten testade att pinga berörd utrustning. På morgonen när tävlingen skulle gå av stapeln och vi kopplat in all utrustning märktes dock att det endast var ping som fungerade. Orsaken var assymetrisk och suboptimal routing. Vilket ledde till att all trafik gick genom brandväggen. Då vi hade ont om tid löstes detta genom att öppna upp brandväggen för den berörda trafiken i samband med att problemet med assymetrisk-routing åtgärdades. Förutom detta hade vi inga större problem som hade med vår nätverksdesign att göra. De fel som uppstod berodde mestadels på användare som gjort fel eller trasiga kablar. 6.3.2 Stadsnätet felar Under etapp tre, ute på arena Böle fick vi efter att tävlingen dragit igång reda på att vi av någon anledning inte hade uppkopplingshastigheten 100/100, vilket vi skulle ha fått från vår ISP. Istället hade vi 10/10, det var de ansvariga för streamingen av O-ringen som uppmärksammade oss om detta. Vi ringde då ISP och de sa att felet berodde på Duplex Mismatch. Vi testade då att byta fiberconverter för att se om felet låg där. Detta löste inte problemet och vi ringde återigen till ISP och denna gång framkom det att de av någon anledning trodde att det var hastigheten 10/10 vi beställt. Efter detta åtgärdades felet omgående. 6.3.3 Team Sportia Team Sportia hade på förhand begärt internetaccess med publik IP-adress. Vi löste detta genom att placera en border-switch utanför brandväggen. Vi skapade på denna switch private-vlans. Där Team Sportia placerades i ett isolated-vlan och den promiskuösa porten var WAN-länken. Vi hade till en början vissa problem med att få detta att fungera som vi tänkt men efter en tids felsökning med Team Sportia flåsandes i nacken löstes detta. Team Sportia gjorde också vid några tillfällen livet surt för oss då vi inte under några omständigheter fick bryta deras uppkoppling för att göra förändringar, inte ens nattetid. 6.3.4 Beställning av Utrustning från Cisco O-ringen har ett rätt förmånligt låneavtal med Cisco vilket vi naturligtvis ville utnyttja för att få den utrustning vi behövde, tyvärr så har Cisco en rätt begränsad pool av låneutrustning tillgänglig, och då DreamHack sommar hålls någon månad innan O-ringen går av stapeln så fick vi vänta till bara någon vecka innan avfärd för att få vår utrustning. Ett annat problem med beställningen var att antenner inte skickas med till AP utan måste beställas separat. Det tredje och sista beställningsrelaterade problemet var att de SFPer för fiberanslutning vi beställde enbart klarade av gigabit hastighet, vilket i sig självt inte skulle varit ett problem om det inte vore för att den utrustning som redan fanns på plats enbart hanterade 100 megabit, något vi fick lösa genom att enbart nyttja de 100mbits konvertrar som O-ringen redan hade där vi inte hade möjlighet att länka cisco utrustning till cisco utrustning. Något som kan vara värt att nämna är att låneutrustningen anlände med lite varierande IOS installerad, några enheter saknade T.ex stöd för SSH, men detta var lätt avhjälpt genom att helt enkelt uppdatera där det behövdes. 31
6.3.5 Proxy ARP Resultat När vi först anlände till Mohed och skulle testa själva nätverket några dagar innan tävlingarna började, fick vi problem med att Arena-siten inte lyckades få någon internetåtkomst. VPN tunneln mellan siterna gick upp och det fungerade klockrent internt men inget svar från default gateway och detta när bägge ASA-5520 var kopplade i samma switch. Minst sagt mystiskt, efter åtskilliga timmars felsökning samt kontakt med ISP upptäckte vi problemet, den ASA som tjänade som brandvägg till staden hade ARPAT för bägge adresserna. Detta var problematiskt då vi inte helt enkelt kunde stänga av proxy ARP då denna funktion används för bland annat 1:1 nat vilket behövdes för att ge tillgång till databaservrarna externt till en tredjepart som arbetade på en kartritningsapplikation. Problemet återuppstod lyckligtvis inte under skarp drift då vi aldrig hade bägge ASA-5520 inkopplade i samma switch, undantaget skulle varit den sista etappen som låg mycket nära till staden. Men problemet undgicks genom att helt enkelt införliva ARENA nätet i STADEN nätet och eliminera behovet av en andra ASA. 32
Bilagor 7 Bilagor Bilaga 1 Bandbreddsanvändning Bandbreddsanvändning Bandbreddsflöde under tävlingsdagarna från staden. Bandbreddsflöde under tre tävlingsdagar från staden, fredagen (ETAPP 5) flöda all trafik genom stadens ISP länk. Detta märks tydligt på grafen på onsdag, torsdag och fredags användning. Trafikflödet från staden på fredagen, detta var den dagen då belastningen var som högst. 33
Bilagor Bandbreddsanvändning från arenan mot ISP på ETAPP 1-4. Belastning mot ISP (Internet) på arenan under en tävling på förmiddagen. 34