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-6 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)
  • Gå evt uden for comfort-zone og vælg en 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 dirigere 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 , [1]

• 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 den 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 dom 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
• 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 cachie server op på dine web noder (eller deploy nye cache servere), og slå cachine 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å skal minimum bruge 3 DB nodes) ?
  • kan alle noder tage imod writes - eller skal man lave read/write split?

Data 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.