Har ADC en rolle i Cloud?
Nettverkene er bygget annerledes i Cloud. Vi belyser hva som er forskjellig, og hva som fortsatt er det samme.
Tradisjonell Application Delivery Controller (ADC) som Citrix ADC og F5 BigIP har sin opprinnelse i lokale datasenter og er designet i forhold til lokal nettverksarkitektur. I cloud-miljø er nettverkene bygget opp på en annen måte, noe som gjør at vi må tenke annerledes rundt hvordan produktene kan benyttes for å gi samme “high availability” i cloud som i lokale datasenter. Disse produktene har sin berettigelse i cloud-miljø. I denne artikkelen vil jeg gå gjennom hvordan styrkene i ADC kan utnyttes.
Nettverkstopologi
I et tradisjonelt datasenter-nettverk med IPv4 som primær protokoll, kobles IP-adressene til hardware-adresser med ARP-tabeller som ligger i alle maskiner i nettet. I ARP (Address Resolution Protocol) benyttes broadcast i nettverket for å finne hvilke hardware-adresser (MAC-adresser) som eier hvilken IP-adresse. På et ethernet er det MAC-adresser som representerer sender og mottager. Når en maskin skal sende data til en annen og avsender kun kjenner IP-adressen, må den først finne MAC-adressen som skal benyttes for å nå mottageren. Dette gjøres altså ved et ARP-broadcast. Når den har fått svar, pakkes dataene inn i en ethernet-ramme, adressert til mottagers MAC-adresse og sendes ut på nettet. IP-adressen er dermed bare en del av lasten i pakken hva ethernet angår.
Den dynamikken som ligger i ARP benyttes av ADC for å implementere aktiv/passiv high availability cluster. Den aktive noden svarer at den eier IP-adressene når det kommer ARP-forespørsler på nettet. Likeledes, ved failover fra en node til en annen, sendes det ut ARP-oppdateringer på nettet som informerer alle andre om at en virtuell IP (VIP) har flyttet til en ny MAC-adresse.
I cloud-miljø benyttes ikke de samme teknikkene for å koble IP-adresse til maskin. I Azure knyttes IP-adressen til nettverkskort, som igjen knyttes til hver enkelt virtuell maskin. Det er dermed en mindre dynamisk kobling mellom MAC-adresser (Lag 2) og IP-adresser (Lag 3). Dersom en skal flytte en IP, må det aktuelle nettverkskortet kobles fra en VM og kobles til en ny. Det er en metode som fungerer dårlig i et dynamisk HA-miljø
I Azure benyttes derfor en mer statisk tilnærming der man legger en Azure Load Balancer (ALB) utenfor ADC. Da oppstår den litt pussige situasjonen at vi legger en last-balanserer (ALB) på utsiden av en last–balanserer (ADC). Det høres ikke direkte rasjonelt ut. Men ALB er ikke en last–balanserer slik vi normalt forstår begrepet. ALB er mer en router som kan ha flere mulige destinasjoner for trafikken, og destinasjonene er da to ADC der en er aktiv og mottar all trafikk. IP-messig konfigureres samme IP-adresse på VIPene i ADC som tjenesteadressen på utsiden av ALB. ALB videresender altså trafikken med samme IP-adresser som den mottar, med andre ord akkurat slik en router opptrer. For at ALB skal vite hvilken ADC som er aktiv, sender den probe-pakker til en egen port på ADC. Kun en ADC vil svare at den er aktiv og blir dermed mottager av all trafikk som kommer gjennom ALB. ALB får dermed mye samme rolle Cloud som ARP-protokollen har i et tradisjonelt nettverk.
Så hva kan en ADC gjøre i Cloud?
Beskrivelsen over viser relativt tydelig at ADC-plattformene ikke akkurat passer hånd-i-hanske i Cloud-infrastruktur. Så hva er egentlig poenget med ADC i Cloud? Svaret på det spørsmålet ligger på høyere lag i OSI-modellen. Det er på Lag 7 ADC har en jobb å gjøre, og det er også på det laget vi normalt bruker de on–premise. De lavere lagene handler om å få trafikken til og fra ADC.
På Lag 7 har vi samme behov i Cloud som vi har On-Premise:
- Lastbalansering
- Responder policies. ADC sender svar til bruker, for eksempel redirect til riktig oppstartside eller filtrering av ugyldige forespørsler.
- Rewrite policies. Omskriving av forespørsel fra bruker eller svar fra server. Benyttes ofte når en applikasjon har kode som ikke passer helt inn i driftsmiljøet.
- Web Application firewall (WAF). For eksempel beskyttelse mot SQL Injection og Cross Site Scripting. Også signaturbasert deteksjon. Siden nærmest all trafikk over Internet i dag er kryptert må sikkerheten etableres i et endepunkt som faktisk dekrypterer trafikken og som kan analysere innholdet før det videresendes. Her kommer ordinære Firewaller til kort siden de sjelden dekrypterer trafikken.
- Autentisering av brukere foran applikasjonen (Pre-Authentication). Dette er kanskje funksjonen som kan størst effekt. Når vi sørger for å autentisere brukeren før trafikken i det hele tatt slippes videre til bakenforliggende servere, fjernes de aller fleste angrep.
Om en applikasjon kjører i Cloud eller On-premise, har liten betydning for hvilke krav applikasjonen har for sikring av trafikk, lastbalansering og HA. Her ser vi at de innebygde verktøyene i Cloud-plattformene har et stykke å gå før de når opp til Citrix ADC og F5 BigIP når det gjelder fleksibilitet og stabilitet.
På samme måte som ADC kommer fra On–Premise, kommer også mange applikasjoner fra den kanten. De er da ikke nødvendigvis skrudd sammen for å dra nytte av de native verktøyene i Cloud for autoscaling, lastbalansering osv. En ADC er dermed ofte et naturlig støtteverktøy for applikasjoner også i Cloud.
Det finnes også gode maler for å deploye ADC i Cloud. Disse setter opp hele den nødvendige infrastrukturen, inkludert elementer som for eksempel ALB.
Konklusjon
Tradisjonelle ADCer har mye funksjonalitet å tilføre Cloud-miljø, funksjonalitet som er vesentlig for å kunne tilføre applikasjonene et ekstra lag av sikkerhet. Dette betinger imidlertid at en faktisk utnytter disse egenskapene i ADC. Dersom det kun er elementær lastbalansering en trenger i Cloud gjør native cloud-verktøy en bedre jobb da de er bedre integrert i nettverksløsningen som benyttes.