Alta disponibilitat

31 març 2015
  • es Español
    • Opinió
    Josep Ma Solanes 0
    | |

    En aquesta entrada exposo la meva idea dels conceptes d’alta disponibilitat i resiliència en els sistemes informàtics. És una entrada més teòrica i filosòfica que pràctica a la que esteu acostumats, però que permet assentar bases a l’hora de dissenyar i desplegar sistemes informàtics productius en quant a la tolerància a errades del mateix. Sobretot quan es parla dels muntatges de les diferents tecnologies: Hyper-V, VMware, SQL Server, Exchange, servidors de fitxers, frontals web, etc… Sempre tenint en compte que la seguretat o disponibilitat al 100% no existeix mai, els castells més grossos també han caigut. Un sistema és segur o disponible en tant ho sigui el seu component més dèbil.

     

    Alta disponibilitat

    L’alta disponibilitat és un concepte que indica que un sistema (en aquest cas informàtic) estarà disponible la major part del temps possible. Però quant de temps és la majoria del temps possible? Si mirem documentacions i publicitat comencen a sortir números del tipus:

    Disponibilitat Minuts anuals Minuts mensuals
    99,9% 518 (8,6 hores) 43
    99,99% 52 4
    99,999% 5 0,4

    Guau! quina passada no?, però no us deixeu il·luminar per aquests valors, no deixen de ser estratègies de màrqueting que queden molt bé sobre el paper.

    És correcte anar a buscar dispositius que m’ofereixen molts decimals, es suposa que patiré menys en les parades. No obstant, que un dispositiu tingui molts decimals no és sinònim que tot el meu sistema té tots aquests decimals. A l’igual que en seguretat, el sistema estarà tant disponible com el seu component més dèbil ho permeti. Posem un exemple, imaginem que tenim un únic servidor físic que té una disponibilitat del 99,999% (5 minuts de parada anuals). Aquest servidor està virtualitzant dos servidors, un Active Directory i una base de dades a la que accedeixen els usuaris per treballar. El sistema funciona a la perfecció, però tinc una alta disponibilitat del 99,999%? No rotund. Revisant supòsits de la instal·lació:

    • Resulta que el servidor físic disposa de dues fonts d’alimentació que estan connectades al mateix SAI o, exagerant, a la mateixa regleta d’endolls amb un interruptor. Quantes vegades ho hauré vist això. En què l’operari de torn o vosaltres mateixos (posar aquí el nom que vulgueu) involuntàriament ha tocat o s’ha enganxat amb l’endoll sense voler i ha desconnectat el servidor. No seran pas 5 minuts de parada a l’any per tornar a posar en funcionament tot l’entorn, oi? Ja teniu els endolls del servidor connectats a dues línies elèctriques independents? Els cables estan lligats perquè no es puguin estirar involuntàriament oi? Per les dues bandes? També teniu protegit el botó d’apagar la regleta? etc… I ja no diguem que els pot haver passat als dos servidors virtuals que estaven a ple rendiment quan se’ls para de cop…

     

    • El servidor físic disposa de diferents components que tenen un firmware que els fan funcionar. Aquest firmware no està lliure d’errors i, de tant en tant, s’ha d’actualitzar. Algunes actualitzacions requereixen de reiniciar el servidor. Tornem-hi, puc parar el servidor? Estaré més de 5 minuts per actualitzar-lo… Els servidors virtuals s’hauran d’apagar correctament, quant tarden?, etc…

     

    • I la configuració d’emmagatzematge? Em permet perdre discs sense parar el servidor? Els típics RAIDs. Puc canviar el disc sense haver de parar el servidor? Tinc totes les eines a mà per gestionar les reconstruccions dels sistemes RAID?

     

    • Tornant al tema de les actualitzacions, passa el mateix amb l’hipervisor, el sistema operatiu del servidor d’Active Directory i el de base de dades i amb el propi motor de base de dades… Estan contemplades?, quant de temps de parada em suposa? etc…

     

    • I no diguem de la xarxa. Quantes connexions de xarxa té el servidor? Al mateix commutador (switch)? Que només té una font d’alimentació? que està connectat a la regleta… Que s’apaga el commutador i ja no es pot arribar al servidor? En aquest cas, el servidor continua funcionant, però no està disponible pels usuaris. Per ells és com si estigués parat. S’ha contemplat disposar de connexions de xarxa redundades? A un mateix commutador? Amb un nivell de disponibilitat del 99,999% o del 80%? etc…

     

    • I la seguretat? Els serveis estan protegits correctament de possibles atacs externs que els tirin a terra? Tenim un bon disseny de la xarxa? Controlem els accessos interns i externs al sistema? etc…

     

    • La més “xula”, el servidor està ubicat en un lloc adequat i protegit? No estarà pas sota els tubs del desaigua, oi? Ni sota l’aparell d’aire condicionat que pot condensar aigua? És accessible per a qualsevol persona, damunt d’una estanteria qualsevol, ben ventilat, etc…

     

    • I si… poseu el que se us passi pel cap, perquè pot passar..

     

    • etc…

    Són alguns exemples de preguntes que us heu de fer quan es dissenya un sistema d’alta disponibilitat.

    Naturalment, l’alta disponibilitat NO és igual per a tothom ni per a tots els serveis. Alguns sistemes han d’estar disponibles les 24 hores del dia, els 7 dies de la setmana i els 365 dies a l’any. Altres, ho poden estar 8 hores al dia (de 8 a 14 i de 15 a 18) de dilluns a divendres. També pot ser que la base de dades hagi d’estar disponible les 24x7x365, mentre que el sistema de fitxers només ho requereix en horari laboral i l’entorn de connexions remotes fora de l’horari laboral. Són les petites finestres de treball en què es poden dur a terme les tasques de manteniment dels mateixos.

    En el cas que el servei no pugui disposar d’aquesta finestra de temps per les tasques de manteniment, és quan parlem de redundar el servei. És a dir, que dues màquines facin exactament el mateix, per poder passar el servei d’una a l’altra sense afectar o afectant el mínim als usuaris. Així, es poden realitzar tranquil·lament les tasques de manteniment en la màquina alliberada. Un cop acabades, es torna a posar el servei en actiu a les dues o a la què correspongui. Per exemple:

    • L’Active Directory és un servei crític per mantenir la seguretat i el funcionament dels serveis de la xarxa. Per un entorn amb un grau d’alta disponibilitat elevat és un servei que hauran d’efectuar dos o més servidors. Per disseny el servei ja ho permet fer. Quan els dos servidors funcionen, ho fan de forma activa tots dos. En cas de caiguda o parada d’un dels servidors l’altre assumeix tota la càrrega.

     

    • El servei de bases de dades Microsoft SQL Server permet el muntatge amb la base de dades redundada en dos servidors. Un dels servidors té una còpia de la base de dades de forma activa (rep les peticions dels usuaris). Mentre l’altre servidor en té una altra còpia (em protegeixo de la corrupció de l’emmagatzematge de dades) de forma passiva. D’aquesta forma puc passar la base de dades activa d’un servidor a l’altre sense afectar els usuaris.

     

    • Els frontals d’aplicacions web permeten crear granges de servidors en que si un dels servidors que la formen cau, el trànsit es deriva cap els altres que estan vius.

     

    • El servei de correu electrònic Microsoft Exchange permet disposar de les bases de dades redundades i els servidors d’accés balancejats en granges. És com una combinació del mètode de la base de dades i els frontals d’aplicacions.

     

    • També tinc els famosos clústers de tota la vida. En què el servei, normalment, es controla per dos servidors, un el té de forma activa i l’altre de forma passiva. Semblant en el cas del SQL Server a excepció que requereix d’un emmagatzematge compartit entre els servidors i on només hi ha una còpia de les dades. En aquest cas no m’estic protegint davant d’una corrupció o errada de les mateixes. Actualment continua sent bastant habitual en els entorns de servidors de virtualització i fitxers.

     

    • etc…

    S’ha d’analitzar cada servei segons les necessitats del mateix i el què es vulgui oferir, per acabar aplicant l’estratègia més avantatjosa.

    No obstant, a mi no m’agrada parlar d’alta disponibilitat, sinó més aviat de RESILIÈNCIA.

     

    Resiliència

    La resiliència és la capacitat que té un sistema de recuperar-se davant d’un imprevist.

    Mentre que l’alta disponibilitat assegura el funcionament, la resiliència és la capacitat de recuperar el servei davant d’un imprevist. Un exemple. Disposo de dos servidors físics de virtualització treballant en clúster. Un dels dos cau inesperadament. Els servidors virtuals que tenia el servidor que cau, naturalment, s’aturen de cop. El segon servidor se’n dóna compte, agafa els servidors virtuals i els torna a engegar damunt d’ell. El sistema no ha estat disponible durant un període de temps, però ha estat resilient al recuperar ràpidament el servei que estava oferint. Mentre que el servidor amb alta disponibilitat del 99,999%, etc… continua parat, el disseny global del sistema ha permès la recuperació del servei. No obstant, cal reparar el servidor que ha fallat per tornar a l’estat inicial.

    Continuant amb l’exemple, una alta disponibilitat, es produiria en el cas que fallés una font d’alimentació d’un dels servidors físics. La font d’alimentació deixaria de funcionar, però el servidor continuaria operatiu sense una pèrdua del servei, amb la segona font d’alimentació. En aquest cas, no es produiria cap tall en el servei com ha passat en el cas anterior.

     

    Centre de contingència

    El centre de contingència ens serveix en cas d’un desastre total on tenim els servidors amb les dades i serveis. Vaja, que ho hem perdut tot: inundació, incendi, robatori, ensorraments, etc… M’he quedat amb una mà al davant i l’altra al darrera.

    Es tracta de recuperar el servei el més aviat i de la millor forma possible, ser resilient davant aquest tipus d’incident. El centre de contingència pot estar dins la pròpia empresa, en edificis prudencialment separats, o disposar d’un entorn de cloud públic on enviar una rèplica de les dades.

    Normalment els centres de contingència dins la pròpia empresa em permetran una recuperació ràpida amb un menor temps de pèrdua de dades (la última rèplica de dades). Mentre que els centres de contingència públics el temps de pèrdua de dades serà més elevat degut als amples de banda disponibles i la quantitat d’informació que es mou.

    Pensar que en el centre de contingència hi tinc les dades i serveis, però i els usuaris? Heu contemplat com els usuaris podran accedir a aquestes dades? Tindré usuaris? Tindran dispositius per connectar-se?

    Al final torna a ser una balança on tot dependrà dels diners que ens hi deixem i del què passa si deixo d’estar disponible. Cada cas és un món i aplicar el sentit comú no està de més.

    T’ha agradat l’article? El pots compartir a les xarxes socials. També pots deixar la teva opinió, comentari o suggeriment. Gràcies!

    Similar Posts by The Author: