Avantajele Big IP Device Service Clustering (HA) și best practices

Cu toții am auzit de-a lungul timpului cel puțin o dată: “A picat server-ul!” ,  “A picat Firewall-ul!”  ,  “A picat DNS-ul!” , și lista poate continua în funcție de experiența fiecăruia. Și am simțit cu toții cât de neplăcut este sentimentul care ne cuprinde atunci când încercăm să accesăm o aplicație și aceasta nu este accesibilă din diverse motive necunoscute nouă. By the way: a experimentat careva în trecutul apropiat un downtime a aplicației bancare pe care o folosește pentru a gestiona finanțele familiei? Eu da, și credeți-mă – nu e deloc plăcut !!!  (Apropos, dacă vrei să afli cum te pot ajuta soluțiile F5 să oferi clienților care îți folosesc aplicațiile o experiență plăcută și întotdeauna disponibilă, trimite un email la ro-f5@alef.com)

Același lucru se aplică și în cazul soluțiilor Big IP de la F5. Bineînțeles, soluțiile Big IP suportă HA, însă voi explica în continuare ceea ce face diferit HA-ul F5 față de HA-ul altor vendori și altor soluții.

Atunci când vorbim de alți vendori și soluții (routere, Nextgen FireWall, etc), pentru a crea un cluster HA este nevoie, de obicei, de echipamente HardWare identice și versiuni identice ale sistemului de operare. Însă ce se întâmplă atunci când vrem să facem un upgrade al echipamentelor, să le înlocuim cu echipamente noi, mai performante, însă dorim să păstrăm configurația existentă? O soluție ar fi migrarea offline a configurației (de obicei manuală, iar în cazul unor tehnologii mai performante - mai mult sau mai puțin automatizată), asigurându-ne că nu scăpăm din vedere niciun obiect, instalarea noului cluster în datacenter și migrarea traficului de pe vechiul cluster pe noul cluster. Totuși, există un dezavantaj al acestei faze, și acesta constă în timpul de downtime mai mic sau mai mare necesar migrării traficului de producție (switch-uri și VLAN-uri uplink sau downlink, rute BGP, etc). Nu mai punem la socoteală eventuale “scăpări” din migrarea configurației care pot crea neplăceri la migrarea traficului ce pot duce, în cele din urmă la reverse (migrarea înapoi pe vechiul cluster a traficului de producție) și reluarea de la capăt a procesului de migrare a configurației.

În cazul soluțiilor Big IP de la F5, procesul este mult mai simplu, deoarece pentru a crea un device cluster nu este nevoie de soluții hardware identice, și nici măcar exclusiv de soluții hardware (de exemplu, se poate face device cluster sau HA între echipamente “i” series și “r” series, sau între echipamente hardware și VM-uri). Nici măcar versiunea sistemului de operare nu “trebuie” să fie identică, deși este recomandat acest lucru (există, totuși, niște limitări aici și este recomandat întotdeauna să citiți documentația înainte de a începe un proces de HA).

În plus, un alt avantaj al Big IP DSC (device service clustering) este faptul că sunt 2 tipuri de clustere care se pot crea cu soluțiile F5: sync-only și sync-failover. Nu o să întru în detaliile fiecărui tip de cluster, însă pe scurt în cazul sync-only se va sincroniza doar configurația între device-urile din cluster, fără a avea HA în cazul failover, pe când în cazul sync-failover, în afară de sincronizarea configurației există și failover al traficului în cazul în care device-ul activ întâmpină o problemă.

Vom folosi primul timp de cluster (sync-only) atunci când ne dorim doar să sincronizăm configurația între toate device-urile din cluster pentru a avea o omogenitate a configurației peste rețea, sau strict din rațiuni de back-up a configurației, audit, teste în afara producției, etc. Putem folosi acest tip mai ales dacă dispunem de capabilități de procesare cu diferențe mari (de exemplu DSC cu echipamente din seria r și VM-uri)

Cel de-al doilea tip de cluster (sync failover) este evident pentru ce îl folosim – pentru failover. Aici trebuie să ținem cont de faptul că, deși putem crea un cluster între echipamente diferite, este recomandat să folosim echipamente similare și care sunt capabile să preia întreaga procesare a traficului în caz de failover al echipamentului principal. Este ușor de imaginat problema care apare cazul în care un cluster încărcat la maxim și format dintr-un echipament r10800 și un echipament i4600 are probleme, iar întreaga sarcina de procesare a traficului trebuie să fie preluată de echipamentul din seria i.

În cazul exemplului de mai sus, în care dorim să facem upgrade la echipamentele existente (să le înlocuim cu echipamente noi, mai performante) fără a avea niciun fel de downtime, putem obține acest lucru cu soluțiile F5. Pe scurt, pașii pentru a face migrarea traficului de producție pe noile echipamente sunt:

• Introducerea echipamentelor noi în clusterul existent
• Sincronizarea configurației pe noile echipamente (după sincronizare echipamentele noi au aceeași configurație, însă nu procesează încă traficul, prin urmare putem face verificările necesare de conectivitate fără a afecta traficul de producție)
• Failover al traficului de producție pe noile echipamente fără a avea downtime
• Scoaterea din producție a echipamentelor vechi (sau păstrarea lor în cluster pentru back-up).

Putem observa, de asemenea, avantajul faptului că nu mai trebuie să facem migrarea manuală a configurației, sincronizarea acesteia făcându-se automat între device-urile din cluster.

Nu voi descrie în detaliu fiecare din acești pași necesari pentru configurarea device cluster-ului pentru Big IP – există documentație foarte detaliată pentru aceasta, disponibilă pe techdocs.f5.com

Totuși, există câteva recomandări de care trebuie să țineți cont dacă doriți ca procesul de creare a clusterului să fie de succes și fără probleme care vor necesita troubleshooting. Aceste recomandări sunt descrise în documentație, însă, din experiență pot spune că mulți dintre noi citim documentația “pe repede înainte”, ceea ce duce, uneori, la omiterea unor pași aparent banali, însă absolut necesari pentru ca procesul să se încheie cu succes.

În primul rând trebuie să fim atenți la licențierea echipamentelor pe care dorim să le introducem în cluster și provizionarea lor. Astfel, dacă în vechiul cluster folosim servicii diverse (LTM, AFM, WAF), iar pentru noile echipamente achiziționăm doar licența LTM, vom avea probleme la formarea clusterului. La fel și în cazul în care, deși am achiziționat și celelalte licențe, nu vom proviziona corect serviciile. Astfel, este recomandat ca licențele și provizionarea serviciilor echipamentelor noi, pe care dorim să le introducem în cluster, să fie identice cu echipamentele existente în producție. Putem verifica statusul licențierii și provizionarea mergând în GUI la meniul System -> License:

System -> Resource Provisioning

De asemenea, un aspect banal la prima vedere, însă deosebit de important, este ca server-ul/ele NTP să fie corect setat/e pe noile echipamente înainte de a fi introduse în cluster. Putem verifica setările NTP din meniul System -> Configuration -> Device -> NTP:

Și, bineînțeles, dacă folosim hostname-uri pentru pool members sau chiar pentru server-ul NTP, este necesar să definim corect serverele DNS accesând meniul System -> Configuration -> Device -> DNS:

O altă problema pe care am întâlnit-o la adăugarea unui nou device într-un cluster existent se referă la declararea self IP-urilor non-floating, care sunt specifice doar acelui device (de tip local only) și care nu vor fi sincronizate cu celelalte echipamente. Astfel, deși acest aspect al alocării corecte a IP-urilor este de la sine înțeles, doar o singură neatenție la declararea netmask-ului, de exemplu, va duce la eroare de sincronizare a config-ului între clustere. Prin urmare, înainte de a adauga noul echipament în cluster, asigurați-vă că toate self IP-urile sunt declarate corect în meniul Network -> Self Ips și în concordanță cu schema existentă a IP-urilor din producție:

Și, nu în ultimul rând, trebuie să ne asigurăm că noile echipamente au instalate certificatele valide pentru a fi putea autorizate în cluster, și putem verifica acest lucru din meniul System – Certificate Management:

Bineînțeles, toate aceste aspecte sunt detaliate în documentația F5, însă, așa cum am spus mai sus, experiența spune că nu toata lumea citește cu atenție documentația, iar mulți dintre noi suntem luați prin surprindere atunci când întâmpinăm dificultăți la configurarea cluster-ului.

Sunt și alte aspecte de care trebuie să țineți cont atunci cand doriți să introduceți noi echipamente în cluster, ce nu țin de tehnologia F5 în sine, precum cablarea corectă, conectarea în VLAN-urile corespunzătoare, etc, însă acestea nu fac subiectul blogului de astăzi.