Customizarea unui monitor HTTP

Vom considera că celelalte obiecte necesare pentru a putea accesa aplicația WEB sunt deja create, astfel:

• Virtual Server: vs_http

  Navigăm la: Local traffic -> Virtual Servers -> Virtual Server List -> http_vs

  
• Pool-ul de servere: http_pool

  Navigăm la: Local traffic -> Pools -> Pool list -> http_pool

  

Cu aceste obiecte create, aplicația WEB poate fi accesată de utilizatorii externi.

În continuare vom atașa un monitor HTTP pentru a monitoriza pool-ul de servere. Pentru început vom folosi monitorul HTTP built in, care arată în felul următor:

Navigăm la: Local traffic -> Monitors -> http

Observăm că acest monitor trimite un mesaj GET către membrii pool-ului de servere, fără a aștepta un anumit răspuns - orice răspuns primit este considerat valid.

Pentru asignarea monitorului trebuie să accesăm meniul Big IP și să navigăm astfel:

Local traffic -> Pools -> Pools list -> http_pool

În acest fel Big IP monitorizează pool-ul de servere de aplicații trimițând periodic un mesaj GET și așteptând un răspuns, iar în cazul în care un răspuns (orice răspuns) este primit, atunci membrii pool-ului sunt considerați disponibili, iar Big IP îi folosește pentru balansarea traficului.

Totuși, se poate observa faptul că monitorul HTTP default este destul de basic, Big IP considerând ORICE răspuns primit de la membrii pool-ului de servere de aplicații ca fiind un răspuns valid (câmpul “Receive String” este gol), prin urmare chiar și un răspuns de eroare 4xx sau 5xx va fi considerat valid, iar Big IP va utiliza în continuare acel membru pentru balansare, deși este evident că răpunsul este unul de eroare iar aplicația nu este disponibilă pe acel membru.

Prin urmare, deși putem folosi monitorul HTTP built in, este recomandat să customizăm răspunsul pe care îl așteptăm (“Receive String”) și putem face asta creând un monitor nou HTTP plecând de la cel default.

Astfel, pentru crearea unui monitor nou trebuie să navigăm la Local traffic -> Monitors -> Create

Vom customiza răspunsul pe care îl așteptăm, astfel:

Observăm că față de monitorul default HTTP am customizat mesajul “Receive String” cu un mesaj pe care îl așteptăm de la un membru valid și disponibil (“SERVER OK”), prin urmare doar un mesaj care conține acest string este considerat valid și va “marca” acel membru ca disponibil pentru balansare.

Vom asigna noul monitor pool-ului de servere, astfel:

Local traffic -> Pools -> Pools list -> http_pool

În acest moment, Big IP va considera ca disponibili doar pe acei membrii ai pool-ului de servere de la care primește răspunsul “SERVER OK”, iar orice alt răspuns de la un anumit membru va “marca” acel server ca fiind indisponibil și nu îl va mai folosi pentru balansarea noilor conexiuni.

În acest fel ne asigurăm că vor fi folosite doar serverele disponibile pentru balansarea traficului, iar experiența utilizatorilor va fi optimă.

Putem, totodată, așa cum am spus la începutul acestui articol să folosim monitorul HTTP customizat pentru a dezactiva automat un server de aplicații din pool-ul de servere atunci când avem nevoie să executăm operațiuni de mentenanță pe acel server.

Astfel, putem customiza câmpul “RECEIVE DISABLE STRING” din configurația monitorului, astfel încât Big IP monitorizează răspunsul primit de la serverele de aplicații, iar atunci când primește un răspuns similar celui din câmpul “RECEIVE DISABLE SRING” de la un anumit membru va dezactiva automat acel server și nu îl va mai lua în calcul la balansarea următoarelor conexiuni, fără a fi nevoie de intervenția administratorului echipamentului Big IP.

Prin urmare, administratorul server-ului respectiv poate modifica răspunsul pe care server-ul îl trimite către Big IP înainte de a scoate server-ul din producție pentru mentenanță, așteptând, de exemplu, conexiunile existente sau cele persitente să se închidă gracefully. Și poate face acest lucru fără să aibe access la echipamentul Big IP, ci doar modificând răspunsul server-ului.

Pentru acest lucru, trebuie să modificăm monitorul customizat existent, adăugând un anumit răspuns așteptat în câmpul “RECEIVE DISABLE STRING”:

Navigăm la: Local Traffic -> Monitors -> my_http_monitor

Prin urmare, având această configurație aplicată monitorului assignat pool-ului de servere de aplicații, administratorul serverelor care dorește să scoată din producție un anumit server pentru mentenanță poate aștepta până când conexiunile existente sunt terminate "gracefully", după care poate modifica răspunsul pe care server-ul respectiv îl trimite către Big IP din “SERVER OK” în “SERVER DOWN FOR MAINTENANCE”, iar Big IP va dezactiva automat acel membru și nu îl va mai lua în considerare pentru balansarea următoarelor conexiuni.

În sens invers, atunci când administratorul a terminat de efectuat mentenanța asupra server-ului și dorește să îl reintroducă în producție, va schimba răspunsul pe care server-ul îl trimite la comanda GET lansată de către Big IP din “SERVER DOWN FOR MAINTENANCE” în “SERVER OK”, prin urmare Big IP va consideră din nou acel membru că fiind activ și îl va lua din nou în calcul la balansarea noilor conexiuni. Și asta fără a face nici o altă modificare la configurația Big IP.