Udvidet linux - webserver

Udvidet linux - webserver

Forskellige opgaver vedr linux - skal ses som en udvidet af de mere trivielle skole linux opg.

Slut resultatet når alle øvelser er lavet, skulle gerne være et fuldt Highly-Available web cluster udelukkende med opensource komponenter.

I øvelserne kan der være brugt begreber der ikke er forklaret yderligere - her er det et selvstudium at undersøge det videre.

Requirements

• Basal linux viden: skal kunne installere linux og navigere rundt, edit config filer mm
• Mulighed for at deploy'e 5-10 små linux vm'er á min 1 cpu/512mb ram - eller have tilsvarende antal raspberry Pi's ved hånden.
  • I øvelserne bruger vi som udgangspunkt 1 rolle pr node - for at holde det simpelt og adskilt.

Basic webserver

• Find en web application du vil hoste i dit cluster.
  • Skal være en applikation der bruger data fra en database
  • Det er valgfrit hvad man vælger (kan være en php app på apache med mysql, ruby app på nginx med redis, java på tomcat med postgresql, nodejs med mongodb osv)
  • Gå evt uden for comfort-zone og vælg sprog/webserver/db som du ikke har prøvet før
• Installer 1 webserver node (web01) og 1 database node(db01)
  • installer webserver og database server softwaren
  • deploy din web application på web01, sæt den til at bruge db01
  • sikre web applikationen virker efter hensigten

High Availability WebServer

Du begynder at få traffik på dit site. Ved spids-belastninger kniber det for web01 at følge med - desuden er du nervøs hvor hvad der sker hvis web01 crasher - derfor vil du gerne have en webserver mere.

• Installer endnu en webserver node (web02) eller lav en clon af web01 (husk at rette hostname, ip osv)
  • Sikre at applicationen virker som forventet når du tilgår web02 i browseren

Du skal bruge en loadbalancer foran dine webservere til at fordele trafikken. Sådan en node kaldes også en reverse proxy

Der er mange forskellige pakker der kan bruges her. Se f.eks. haproxy , apache mod_proxy , nginx (Skulle der bruges en Enterpri$e løsning her, kunne det f.eks. være citrix netscaler)

• Installer en node til din loadbalancer (lb01)
• installer en proxy/loadbalancer efter eget valg og sæt den til at kunne forwarde trafikken til både web01 og web02.
  • For variationens skyld så lad være med at bruge samme server som på web01/web02, så du ikke bruger f.eks. nginx til både lb og web
• du skulle nu kunne tilgå din webapp gennem lb01
• haproxy har en indbygget status side, apache mod_proxy kan sættes til at vise status igennem mod_status, og nginx har også en status side. Bruger du andet, se om den kan rapportere status på lignende måde.
  • Sæt proxy status siden op lb01
• test nu at din LB kan håndtere at en webserver ikke svarer
  • ved hvert step følg med på status siden
  • stop webserver på web01 og sikre at du stadig kan bruge din app gennem lb01
  • start webserver på web01 og stop den på web02 - sikre at du stadig kan bruge din app gennem lb01
  • start webserver igen på web02

De fleste reverse proxyer understøtter flere metoder til load balancing, når den skal finde ud af hvilen server der skal håndtere en given http request, f.eks. round-robin, by-source-ip, eller least-used.

• Undersøg hvilke metoder din reverse proxy understøtter.

Hver opmærksom på at hvis din applikation bruger logins eller sessions på anden vis, skal en bruger helst ramme samme server hver gang. (dog er det undtaget hvis at du har sat clustered sessions op i din applikation)

• Undersøg om du kan lave sticky-sessions eller om du vil lave balance by ip

Ud over at din LB gerne selv skulle kunne detektere at en node ikke er tilgængelig, så vil du også gerne kunne disable en webserver i LB i forbindelse med servicevinduer, så at LB ikke forgæves prøver at sende trafik førend webserveren er klar igen.

• Undersøg hvordan du kan disable og enable en webserver i din LB pool

Synkronisering af webserver

Du har nu 2 webservere kørende, som helst skulle køre nøjagtig samme udgave af web applikationen. Så du skal overveje hvordan sikrer du dig at dette fortsætter med at være tilfældet i forbindelse med upgrade eller hvis du har behov for at deploye endnu en server. Hvis man kan uploade filer gennem applikationen så skal alle webserverne helst have samme view af upload mappen.

php filer kan synkroniseres, ved andre apps kan det være nødvendigt at undersøge config mgmt tools såsom salt,puppet eller ansible.

filer kan synkroniseres med f.eks. rsync - eller man kan lave replikerede filsystemer med f.eks. drbd/gluster - du kan også store dem på en seperat server og mounte via NFS (men hvordan påvirker det så dit mål om HA?)

• Hvad vil bruge for at sikre dine web servere er identiske ?

High Availability LB

Dine webservere er redundate og LB sørger for at omdirigere trafikken, hvis en crasher - men hvad med din LB? Så du skal nu lave en lb mere - men hvordan sikrer du HA mellem de 2? Måden der skal bruges her er at lave en shared virtual IP som de skal forhandle om at være primær på. Vær ops på at shared IP kan give problemer hvis din router/fw har lang levetid på arp cache !!

• Deploy en ny LB node (lb02) og sikre at configurationen matcher med lb01
• sikre at du kan tilgå dit website gennem lb02
• opsæt virtual shared IP på lb01 og lb02 med f.eks. heartbeat / pacemaker eller keepalived.
• test at din HA virker på shared IP (luk lb01 ned og test, start lb01 og luk lb02 osv ...)

Optimering af applikation

Du får mere traffik og dine 2 webservere kan ikke følge med længere. Inden du kaster flere hardware resourcer ind i løsningen bør du kigge på om applikationen er fintunet.

• Hvis det er en php applikation:
  • Undersøg hvad en opcode cache er
  • Slå opcode caching til på dine webservere
• Hvis det er java
  • Passer dine memory settings til dit miljø (-Xmx / -Xms)
  • Passer din garbage collector til applikationen og belastningstypen
• Hvis det er et 3 sprog - se om der er nogen ting der skal tunes i runtime opsætningen

• Du bør også kigge på om din database er tunet korrekt
  • mysql: se på f.eks. innodb_buffer_pool_size
  • postgres: se f.eks. på shared_buffers
  • undersøg hvad der passer til din database type

• De fleste applikationer vil kunne bruge en caching komponent til at gemme data, så at den ikke behøver at hente samtlige elementer fra databasen ved hver side visning. Populære cache servere er memcached og redis.
  • undersøg om din applikation kan bruge en sådan caching løsning. Sæt cache server op på dine web noder (eller deploy nye cache servere), og slå caching til i din applikation
  • lav benchmark med f.eks. apache ab af respons tid med og uden cache

HA Database

Du kan på nuværende punkt skalere dit webserver lag horisontalt - men hvad med databasen? Den er stadig single point of failure - så hvis den crasher er du stadig på den.

• Undersøg hvad du har af muligheder for at skalere din DB.
  • Er din løsning en fuld replika ... eller laver du data partitionering (sharding) -i såfald er du nu afhængig af at begge kører?
  • Er din løsning en warm standby, hot standby eller active/active
  • Er der nogen regler omkring quorum (så du skal minimum bruge 3 DB nodes) ?
  • Hvad betyder split-brain?
  • kan alle noder tage imod writes - eller skal man lave read/write split?
  • Er der noget der skal ændres manuelt hvis en node crasher?
• Prøv at se om du kan sætte det op med db02 og evt db03
• Hvordan omkonfigurerer du din web applikation til at bruge DB clusteret
  • Skal du bruge en database load balancer ?

Database replikering kan være kompliceret at sætte op - så det er superfedt hvis du kan få det til at virke - men okay hvis du kaster håndklædet.

Static content

Du er nu fuldt HA og har redundans på samtlige elementer,, men dine webservere har problemer med at følge med. Du kunne lave en webserver mere - men lad os nu antage at de serverer en stor mængde statisk indhold (f.eks. billedfiler) - og det er ikke sikkert at din webserver er optimal i forhold til dette. Nogle er bedre til den slags requests: nginx eller lighttpd (apache kan bruges hvis du disabler .htaccess og bruger en threaded mpm)

• lav 1 eller 2 noder til static content (staticweb01 / staticweb02) og installer en "letvægts" http server
• find noget static content fra din app der kan kopieres over til staticweb01/02
• undersøg hvordan du i dine LB noder kan route request til staticweb01/02 ud fra en del af url'en (f.eks. en /static mappe)

Denne måde med at route trafik ud fra request kan også bruges hvis du f.eks. har flere forskellige applikationer bag samme LB - her vil man måske bare route ud fra requested hostname istedet for en sti

WebCache

Hvis du har et højt antal side visninger af samme content f.eks. visningen af forsiden på dit site - kan man offloade webserveren ved at lade en reverse proxy servere en cachet udgave af siden. Derved kan man spare en del resourcer på web og database serverne. Jeg vil her anbefale at bruge varnish men man kan også kigge på f.eks. apache mod_cache sammen med mod_proxy eller nginx proxy_cache

• Lav 2 noder webcache01 og webcache02
• setup en caching server på dem begge
  • caching serveren skal kunne trække data fra web01 og web02
  • omkonfigurer lb01/02 til at hente data fra webcache01/02 istedet for web01/02
  • configurer din cache til f.eks. at den må cache forsiden - men alt andet skal trækkes fra webserver

Nu er det ikke længere kun lb men også dine webcache nodes der skal tage højde for korrekt session routning

X-Forwarded-For

Med disse disse lag af proxy server - vil web serverne kun se IP på den proxy server der har videresendt trafikken til den. Dvs at webservernes log filer får et forkert billede af hvem der forespørger på hvad. En måde at styre det på er at få proxy serveren til at inject en http header med oprindelig requester ip - her bruges tit x-forwarded-for.

• Undersøg hvordan du får dine proxy servere til at videre sende x-forwarded-for
• Undersøg hvordan du får din webserver til at trække requester ip fra x-forwarded-for
• verificer at ved request er det klientens IP der gemmes i webserver logfilen

WAF - Ekstra opg

Hvis du vil beskytte dit website kan du implementere en såkaldt Web Application Firewall (WAF). En traditionel firewall kigger på IP og TCP pakker - mens at en WAF inspicerer HTTP requests.

En opensource WAF du kan kigge nærmere på er https://www.modsecurity.org/

Ready for production

Dit site er toptunet og full HA, og du kan scalere ved at deploye flere noder - men er du production-ready hvis du ikke har overblik over om dine elementer kører eller ej ? Og hvad vil du gøre hvis hele dit datacenter futter af ?

Monitorering

• Undersøg opensource monitorerings løsninger ( f.eks. icinga eller zabbix )
  • prøv at lave en simpelt monitorering hvor du som minimum laver ping check af dine servere

Backup

• Du kan kigge på f.eks. bacula - men du må også gerne holde det simpelt.
  • Lav som minimum en backup af din database automatisk en gang i døgnet