Tjenester i skyen. 19. desember

Transkript

1 Sky med netthatt

2 Tjenester i skyen Det blir mer og mer aktuelt å flytte tjenester ut av campus og inn i en eller annen form for sky. Å sentralisere tjenester enten nasjonalt slik som UH-skype eller UH- AD. I forbindelse med sammenslåing av institusjoner vil man også slå sammen like tjenester og tilby dem fra et eller to sentrale campus Kanskje ønsker man seg sentral backup eller lokasjonsredundans 19. desember

3 Nettkompetanse Ofte kommer nettfolk inn etter at en slik avgjørelse om å flytte ting inn i skyen er tatt. Utfordringer rundt nett blir ofte ikke tatt opp før de faktisk kommer opp i dagen og ting ikke fungerer som forventet. Da kan det være for sent. Nettfolk har ofte en unik kompetanse for å kunne se helheten i en tjeneste fra lag 1 til lag 7. Og vil kunne bringe inn viktig kunnskap i prosessen og se til at overgangen bli så lite merkbar for sluttbrukerne som mulig. Viktigheten av et fungerende nettverk og kompetansen rundt dette forsvinner ikke selv om man flytter tjenestene ut i skyen. 19. desember

4 Suksessfaktorer Kom tidlig inn i planleggingsfasen Samarbeide tett med tjenestedrift eller de som har kompetansen på tjenesten. Forstå hvordan tjenesten/applikasjonen fungerer. Involvere skyleverandør og få et godt innblikk i hvilke tjenester de kan og ikke kan tilby. Og ikke minst hvordan de er realisert. 19. desember

5 Er det så mye å tenke på da? Båndbredde/Ledig kapasitet i nettet Rundreisetid Redundans Sikkerhet Adressering Ansvarsforhold Brukeropplevelse 19. desember

6 Båndbredde/Ledig kapasitet i nettet Vi må ha nok ledig kapasitet slik at kan ta trafikktopper uten å måtte kaste pakker. Pakketap er drepen på TCP-ytelsen I forskingsnettet har vi god kontroll på at linjene våre ikke blir for høyt belastet. Men vi har ikke samme oversikt utenfor vårt eget nett. Mot en skyleverandør kan det også være andre faktorer som påvirker båndbredden som f.eks. enheter som gjør NAT, tunellering og kryptering og som ikke skalerer godt nok i forhold til den båndbredden man har behov for. 19. desember

7 Rundreisetid Det går jo raskt på lokalnettet men mye tregere mellom forskjellige campus. Er det noe feil med nettet? Mange applikasjoner er laget med tanke på å fungere i en lokalnett og har ikke de rette mekanismene for å yte godt nok med høy forsinkelse. Eldre OS kan også mangle automatikk eller de rette knappene for å kunne justere for høy ytelse over avstand. Både klient og tjener må kunne ta høyde for en økt forsinkelse. Forutsetning for god ytelse er at stien mellom sender og mottaker må fylles best mulig. 19. desember

8 Rundreisetid De tre faktorene som påvirker ytelsen desidert mest er pakketap, rundreisetid og TCP vindusstørrelse Ytelsen(MB/s) = TCP-vindu(KB) / RTT (ms) Mye av begrensingene vi ser er når vi overfører data over lengre avstander kommer av økt RTT. Lyshastigheten i fiber er det lite vi kan gjøre noe med. 19. desember

9 Vindusstørrelse Standard vindusstørrelse er i flere applikasjoner er 64KB f.eks. SSH/SCP. Microsoft CIFS er default satt til 17,5KB men kan justeres opp. SMB/SCP Oslo-Tromsø med 64KB vindusstørrelse Ytelse <= 64 / 25ms =2MB/s = 16Mbit/s SMB/SCP LAN med 64KB vindusstørrelse Ytelse <= 64 / 0,8ms =80MB/s = 640Mbit/s 19. desember

10 19. desember

11 Vindusstørrelse Nyere OS har auto-tuning av TCP vindusstørrelse, men det kan likevel være lurt å sjekke grensene. Få OS har gode maks TCP-vindu for virkelig høy ytelse. Store vinduer kan også virke negativt om man ikke har god kvalitet i nettet. Pakketap gir da en forsterket negativ effekt. Iperf3 er et bra verktøy for å teste og eksperimentere med f.eks. TCP-vindu. 19. desember

12 Redundans Flytter man tjenester ut av campus er det flere komponenter som kan feile og redundans blir enda viktigere hele veien mellom klient og tjener. Doble rutere og BGP bør på plass. Redundante linjer inn til campus og helst i redundante føringsveier Georedundans bør skje på applikkasjonslaget og ikke med fancy L2 tunnelering. For tjenester det passer for kan anycast være en mulighet. 19. desember

13 Sikkerhet Hvordan skal man opprettholde samme sikkerhetsnivå når man flytter tjenester ut i skyen? Vil det være vanskeligere å administrere filtreringen? Er applikasjonen ende til ende kryptert? Vil det være sensitive personopplysninger som hindrer bruk av skyleverandører plassert i utlandet? 19. desember

14 Adressering Hvordan har en skyleverandør implementert adresseringen av tjeneren din? Vil du kunne få IPv6? Vil IPv4 adressen til serveren være en RFC1918 adresse som det gjøres 1-1 NAT på? Kan vi benytte våre egne adresser? 19. desember

15 Ansvarsforhold Avhengig av god dokumentasjon av plattformen som tilbys både på funksjonalitet, ytelseskrav. Hvem har ansvar for hva og hvordan er kontaktpunkt for feilsøking Hvilke verktøy har man for feilsøking. Fungerer ping og traceroute? Hva med overvåking? Hvor raskt finner vi feilen? Blir vi varslet om feilen ligger hos skyleverandøren? Hva om feilen er komplisert og ikke lett kan føres tilbake til en av partene. 19. desember

16 Brukeropplevelse Klarer vi å levere en like god tjeneste i skyen Vil fillagring i skyen være like rask? Vil applikasjoner som krever raskt oppdatering oppleves like bra? Vil vi som driftsfolk kunne gi samme support som før eller er vi mere avhengig av en tredjepart for å løse eventuelle feil. 19. desember

17 UH-sky tjenester I dag har vi UH-skype som er lokalisert på i UiT og NTNU sitt nett Vi har UH-AD som endel benytter og som er plassert i UiO sitt nett Vi ser nå på muligheten til å etablere nye UH-tjenester nærmere forskingsnettet. I en mere standardisert topologi og med GEOredundans. Det vil likevel være mulig for institusjoner å fortsatt drive tjenestene for sektoren. Tett integrasjon med forskningsnettet gir oss god oversikt over infrastruktur og mulighet for raskere å lokalisere feil. Ende til ende overvåking og trafikktellere/feiltellere 19. desember

18 UH-sky tjenester UH-MX kan være en tjeneste vi ønsker å etablere i et slikt miljø. Eksisterende tjenester kan også flyttes til en slik infrastruktur om det er mulig og ønskelig. 19. desember