Difference between revisions of "Udvidet linux - webserver"

From HoerupWiki
Jump to: navigation, search
(→‎WAF - Ekstra opg)
 
(53 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
Forskellige opgaver vedr linux - skal ses som en udvidet af de mere trivielle skole-linux opg.
+
=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.
 
Slut resultatet når alle øvelser er lavet, skulle gerne være et fuldt Highly-Available web cluster udelukkende med opensource komponenter.
Line 5: Line 6:
 
I øvelserne kan der være brugt begreber der ikke er forklaret yderligere - her er det et selvstudium at undersøge det videre.
 
I øvelserne kan der være brugt begreber der ikke er forklaret yderligere - her er det et selvstudium at undersøge det videre.
  
−
Requirements:
+
== Requirements ==
 
* Basal linux viden: skal kunne installere linux og navigere rundt, edit config filer mm
 
* 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.
+
* 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.
 
** I øvelserne bruger vi som udgangspunkt 1 rolle pr node - for at holde det simpelt og adskilt.
  
Line 14: Line 15:
 
* Find en web application du vil hoste i dit cluster.  
 
* Find en web application du vil hoste i dit cluster.  
 
** Skal være en applikation der bruger data fra en database
 
** 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)
+
** 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 en sprog/webserver/db som du ikke har prøvet før
+
** 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 1 webserver node (web01) og 1 database node(db01)
 
** installer webserver og database server softwaren
 
** installer webserver og database server softwaren
 
** deploy din web application på web01, sæt den til at bruge db01
 
** deploy din web application på web01, sæt den til at bruge db01
 
** sikre web applikationen virker efter hensigten
 
** sikre web applikationen virker efter hensigten
 +
 +
 +
<graphviz>
 +
graph basic{
 +
node [fontsize=10]
 +
edge [fontsize=10]
 +
 +
web01 -- db01
 +
 +
}
 +
</graphviz>
  
  
Line 30: Line 42:
  
  
−
Du skal bruge en loadbalancer foran dine webservere til at dirigere trafikken. Sådan en node kaldes også en [https://en.wikipedia.org/wiki/Reverse_proxy reverse proxy]
+
Du skal bruge en loadbalancer foran dine webservere til at fordele trafikken. Sådan en node kaldes også en [https://en.wikipedia.org/wiki/Reverse_proxy reverse proxy]
  
−
Der er mange forskellige pakker der kan bruges her. Se f.eks. [http://www.haproxy.org/ haproxy] , [https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html apache mod_proxy] , [https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/]
+
Der er mange forskellige pakker der kan bruges her. Se f.eks. [http://www.haproxy.org/ haproxy] , [https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html apache mod_proxy] , [https://docs.nginx.com/nginx/admin-guide/web-server/reverse-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 node til din loadbalancer (lb01)
Line 38: Line 51:
 
** 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
 
** 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
 
* 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.
+
* 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
 
** Sæt proxy status siden op lb01
 
* test nu at din LB kan håndtere at en webserver ikke svarer
 
* test nu at din LB kan håndtere at en webserver ikke svarer
Line 51: Line 64:
 
* Undersøg om du kan lave sticky-sessions eller om du vil lave balance by ip
 
* 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.
+
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
 
* Undersøg hvordan du kan disable og enable en webserver i din LB pool
  
 +
 +
{{#tag:graphviz|graph network {
 +
node [fontsize=10]
 +
edge [fontsize=10]
 +
 +
 +
lb01 -- web01
 +
lb01 -- web02
 +
web01 -- db01
 +
web02 -- db01
 +
 +
}|format="png"}}
  
 
=Synkronisering af webserver=
 
=Synkronisering af webserver=
Line 76: Line 101:
 
* test at din HA virker på shared IP (luk lb01 ned og test, start lb01 og luk lb02 osv ...)
 
* test at din HA virker på shared IP (luk lb01 ned og test, start lb01 og luk lb02 osv ...)
  
 +
{{#tag:graphviz|graph ha_lb {
 +
node [fontsize=10]
 +
edge [fontsize=10]
 +
 +
 +
lb01 -- web01
 +
lb01 -- web02
 +
lb02 -- web01
 +
lb02 -- web02
 +
web01 -- db01
 +
web02 -- db01
 +
 +
}|format="png"}}
  
 
=Optimering af applikation=
 
=Optimering af applikation=
Line 83: Line 121:
 
** Undersøg hvad en opcode cache er
 
** Undersøg hvad en opcode cache er
 
** Slå opcode caching til på dine webservere
 
** 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.
 
* 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
+
** 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. [https://httpd.apache.org/docs/2.4/programs/ab.html apache ab] af respons tid med og uden cache
 
** lav benchmark med f.eks. [https://httpd.apache.org/docs/2.4/programs/ab.html apache ab] af respons tid med og uden cache
−
 
  
 
= HA Database=
 
= HA Database=
Line 94: Line 141:
 
** 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 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 din løsning en warm standby, hot standby eller active/active
−
** Er der nogen regler omkring quorum (så skal minimum bruge 3 DB nodes) ?  
+
** Er der nogen regler omkring quorum (så du skal minimum bruge 3 DB nodes) ?  
 
** Hvad betyder split-brain?
 
** Hvad betyder split-brain?
 
** kan alle noder tage imod writes - eller skal man lave read/write split?
 
** kan alle noder tage imod writes - eller skal man lave read/write split?
 
** Er der noget der skal ændres manuelt hvis en node crasher?
 
** 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.
 +
 +
{{#tag:graphviz|graph ha_db {
 +
node [fontsize=10]
 +
edge [fontsize=10]
 +
 +
 +
lb01 -- web01
 +
lb01 -- web02
 +
lb02 -- web01
 +
lb02 -- web02
 +
 +
web01 -- db01
 +
web02 -- db01
 +
web01 -- db02
 +
web02 -- db02
  
−
* Prøv at se om du kan sætte det op med db02 og evt db03
 
−
* Hvordan laver omkonfigurerer du din web applikation til at bruge clusteret
 
−
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.
 
  
−
= LB Split =
+
}|format="png"}}
−
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 - 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)
+
 
 +
= 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 light http server
+
* 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
 
* 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)
 
* 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
+
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
 +
 
 +
{{#tag:graphviz|graph static_content {
 +
node [fontsize=10]
 +
edge [fontsize=10]
 +
 
 +
 
 +
 
 +
lb01 -- web01
 +
lb01 -- web02
 +
lb02 -- web01
 +
lb02 -- web02
 +
 
 +
lb01 -- staticweb01
 +
lb01 -- staticweb02
 +
lb02 -- staticweb01
 +
lb02 -- staticweb02
 +
 
 +
 
 +
web01 -- db01
 +
web02 -- db01
 +
web01 -- db02
 +
web02 -- db02
 +
 
 +
 
 +
}|format="png"}}
  
 
= WebCache =  
 
= 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 lave 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
+
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
 
* Lav 2 noder webcache01 og webcache02
Line 119: Line 209:
 
** caching serveren skal kunne trække data fra web01 og web02
 
** 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
 
** 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
 +
 +
<i>Nu er det ikke længere kun lb men også dine webcache nodes der skal tage højde for korrekt session routning</i>
 +
 +
{{#tag:graphviz|graph network_cache {
 +
 +
node [fontsize=10]
 +
edge [fontsize=10]
 +
 +
 +
lb01 -- webcache01
 +
lb01 -- webcache02
 +
lb02 -- webcache01
 +
lb02 -- webcache02
 +
 +
lb01 -- staticweb01
 +
lb01 -- staticweb02
 +
lb02 -- staticweb01
 +
lb02 -- staticweb02
 +
 +
webcache01 -- web01
 +
webcache01 -- web02
 +
webcache02 -- web01
 +
webcache02 -- web02
 +
 +
web01 -- db01
 +
web02 -- db01
 +
web01 -- db02
 +
web02 -- db02
 +
 +
 +
}|format="png"}}
 +
 +
= 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

Latest revision as of 21:33, 23 May 2020

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


This is a graph with borders and nodes that may contain hyperlinks.


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


This is a graph with borders and nodes that may contain hyperlinks.

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 ...)
This is a graph with borders and nodes that may contain hyperlinks.

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.

This is a graph with borders and nodes that may contain hyperlinks.

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

This is a graph with borders and nodes that may contain hyperlinks.

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

This is a graph with borders and nodes that may contain hyperlinks.

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
Retrieved from "https://wiki.t-hoerup.dk/index.php?title=Udvidet_linux_-_webserver&oldid=12136"