KNOWLEDGE BASE

Knowledge Base
1Backup
Acronis
Antivirus
Email
Firewall
GFI Software
Mail
Monitoring
N-Able
Sicurezza
TSPlus

Vai al Video

Business Continuity Disaster Recovery Plan

Il concetto di Business Continuity (letteralmente continuità del business) si riassume sostanzialmente nell’attuare una serie di procedure e tecniche capaci di assicurare la continuità dell’operatività di una realtà produttiva, ovvero di evitare il più possibile che l’attività stessa venga interrotta da fattori di disturbo, incidenti di vario genere e guasi. Nel caso di aziende fortemente supportate dall’IT, la business continuity può essere pregiudicata da malfunzionamenti, attacchi informatici o mancato aggiornamento dell’infrastruttura a livello sia hardaware che software.

In questo tutorial analizzeremo due situazioni che possono interferire con la continuità del business, ossia il Load Balancing e la replica dei database MS SQL e MySQL; questo perché negli scenari in cui sia necessario creare una business continuity in cloud oppure on premises, gli elementi che costituiscono un’infrastruttura che risponda ai criteri di alta affidabilità sono i bilanciatori di carico (ossia sistemi in grado di ripartire il carico di rete su più server) e i sistemi di replica dei dati di un database.

Replica dei database MS SQL E MYSQL

Iniziamo subito con la replica dei database, vedendo quando e perché ricorrere ad essa. Oggigiorno sono sempre più chiamati in causa sistemi che utilizzano dei database server, quindi i siti web, i gestionali ecc., quindi se vogliamo mantenere il nostro gestionale performante e comunque sempre attivo, abbiamo bisogno di avere sempre una replica costante dei dati presenti all'interno dei nostri database, oltre che dell’applicativo;  quando poi andiamo a scalare abbiamo una macchina che fa solo da database server e la macchina con l’applicazione (Application Server) davanti.

I casi d’uso possono essere diversi.

- Business continuity impostando opportunamente il nostro applicativo affinché interroghi un server e in caso quest’ultimo sia giù (down) interroghi l’altro, anche magari utilizzando un software load balacer quale Haproxy, dove impostare il secondo server in stand-by (immagine seguente); Haproxy in caso di mancata attività del server principale riporta tutte le sessioni aperte sul server di riserva.

- Load Balancing, dove possiamo impostare la replica costante tra i nostri due DB server e interrogare e scrivere su entrambi in modo da bilanciare il carico, mettendo a monte un load balancer quale, ad esempio, Haproxy; tale situazione è, ad esempio, quella di un database che può essere molto voluminoso, al punto che in certe condizioni di lavoro un solo server non può reggere il carico e richiede che un load balancer (sullabase di regole da noi definite o predefinite) distribuisca il traffico tra esso e uno o più server di appoggio.

- Backup; quando facciamo i backup dei DB il sistema si può bloccare e questo può essere un problema, soprattutto se dobbiamo fare dei backup frequenti; per metterci al riparo da tale situazione possiamo andare ad impostare un server di replica da cui eseguiremo i backup, così il sistema non risentirà di possibili stop dovuti ai backup.

Proprio nel caso del backup è possibile creare una replica del database su un’altra macchina, cosicché in caso di blocco sulla macchina principale non va giù la replica e appena il server principale si sblocca, riparte e si sincronizza; così non si verifica alcun tipo di down al vostro applicativo (immagine seguente).

Microsoft SQL e mySQL attualmente coprono il 70% del settore dei database e includono già delle funzioni di replica native da configurare da configurare.

Vediamo ora un aspetto legato alla licenza necessaria a eseguire una replica di Microsoft SQL: ebbene, essa è possibile in base all’edizione che abbiamo a disposizione.

La replica va impostata per ogni database che andiamo a creare e va configurata di volta in volta.

La tabella seguente espone la situazione relativa alla fattibilità della replica di Microsoft SQL e delle rispettive funzionalità.

Come vedete, già dalla versione Express si può fare fare la replica, però attenzione che si può solo mandare fuori il database ma non si può ricevere la replica; inoltre non si può eseguire la replica fra due server con installata la versione express ma è possibile tra uno con MS SQL Express e l’altro con la versione standard. Diciamo che più la licenza è avanzata, più sono le combinazioni e le tipologie di rete implementabili.

L’esecuzione della replica è abbastanza semplice: dalla finestra Object Explorer clicchiamo su Replication e poi sulla cartella Local Publication apriamo il menu contestuale di replica, dove impartiamo il comando New Publication (immagine seguente).

Tale operazione aprirà il wizard, nei vari passaggi del quale bisognerà definire inizialmente qual è il database di distribuzione; la best-practice vorrebbe che venisse utilizzato un database Master, uno Slave e poi il database di distribuzione. Comunque si può fare tutto con un’unica macchina, cioè il server che replica il database può essere applicato anche per fare da distribuzione.

Definito il server di distribuzione, si procede con il passaggio successivo e si arriva alla finestra di dialogo proposta dall’immagine seguente, nella quale si deve impostare il percorso per la cartella di Snapshot e la relativa opzione di pubblicazione.

Cliccando su Next si passa oltre e si va alla finestra dove definire il tipo di pubblicazione (di replica) che si desidera (immagine seguente); qui si può scegliere tra vari tipi di replica, ossia replica transazionale (Transactional Publication)  peer-to-peer publication, merge ecc.

In base alle varie opzioni che andiamo a scegliere, poi dobbiamo configurare il server slave; resta inteso che il tipo di pubblicazione selezionabile dipende dalla licenza a disposizione, quindi, per esempio, con una Express possiamo fare la pubblicazione Snapshot ma non quella transazionale e via di seguito.

Procedendo con Next andiamo a selezionare il database in cui vogliamo pubblicare, quindi il database che ci può interessare (immagine seguente).

Procediamo con Next e andiamo alla finestra nella quale definire gli oggetti: questo perché si può anche replicare i singoli oggetti di database e non necessariamente tutto, quindi una certa tabella o altro elemento e via di seguito (immagine seguente).

 

Con Next si passa alle due finestre di dialogo successive, la prima nella quale si imposta l’agent in modo da indicare quando l’agent deve creare lo snapshot (Snapshot Agent) ossia se farlo subito o in un certo orario; la seconda (Agent Secuty) dove specificare i dati di accesso all’agente e le eventuali credenziali (immagine seguente).

Cliccando su Next si va all’ultima finestra, nella quale, cliccando su Finish, si avvia la creazione della pubblicazione; fatta questa siamo pronti per andare a fare la parte di sottoscrizione.

Poi abbiamo lo strumento Replication Monitor che ci fa vedere se ci sono dei problemi, in che stato è la replica eccetera (immagine seguente).

Andando poi nel server slave, clicchiamo sempre nella cartella Replica, quindi clicchiamo con il pulsante destro del mouse su Sottoscrizioni Locali e dal menu contestuale scegliamo Nuove sottoscrizioni (immagine seguente).

 

Nella finestra di dialo che si apre (Creazione guidata nuova sottoscrizione) andiamo a scegliere il server in cui risiede la pubblicazione; se nel menu non compare, si sceglie la voce Trova server di pubblicazione... e mettiamo il nome, cosicché il sistema si aggancia ci mostra qual è la replica, ossia la pubblicazione che avevamo fatto (immagine seguente). 

Nel passaggio successivo si va a scegliere la modalità di pubblicazione, ossia Push o Pull: nel primo caso è gestita dal master e nel secondo dallo slave; se abbiamo già un database andiamo ad agganciarvi la replica, altrimenti partiamo da un nuovo database e si apre la schermata classica di SQL Server dove definire percorso e altre caratteristiche del database da creare.

Le schermate successive riguardano la sicurezza dell’agent, la pianificazione della sottoscrizione e si arriva fino all’avvio della sottoscrizione stessa, il cui completamento sarà confermato da una finestra tipo quella proposta nell’immagine seguente.

Quindi la sottoscrizione va ad agganciarsi (Operazione completata); va ricordato che l’agent SQL dev’essere attivo perché è quello che gestisce le repliche.

Porte firewall per replica geografica in MS SQL

Se dobbiamo fare una replica geografica, abbiamo bisogno di abilitare le porte per consentire le connessioni; per permettere le repliche di Microsoft SQL basta avere aperto la porta standard di SQL, che è la 1433.

Replica database mySQL

Passiamo adesso alla replica in mySQL, la quale è ancor più semplice da configurare rispetto a quella di Microsoft SQL. La replica di DB MySQL comporta qualche passaggio in meno rispetto a quella di MS SQL ed avviene su tutti i database; una volta impostata, basta creare il nuovo database, che automaticamente viene creato sul server di replica.

Quello che dobbiamo fare è modificare i file di configurazione sia del server master che di quello slave, per indicargli di attivare le repliche.

La replica è concettualmente schematizzata nell’immagine seguente.

Per configurare la replica si entra nella configurazione del master, si va a impostare un ID del server di replica, poi a definire quali sono sono i percorsi dei file di log della rete, per quanto tempo devono essere mantenuti questi file (importante perché sennò cresce lo spazio occupato, soprattutto se il database è voluminoso). Si deve anche indicare quali sono eventuali database da ignorare (perché per default vengono replicati tutti), cosa che è utile perché ad esempio i DB mysql e information_schema non possono essere replicati senza che sorgano dei problemi.

Di seguito vedete un un esempio di file di configurazione, con ben visibili i comandi (binlog) per ignorare i due predetti database.

nano /etc/mysql/mysql.conf.d/mysqld.cnf

server-id = 437811

log_bin = mysql-bin.log

log_error = mysql-bin.err

expire_logs_days = 1

binlog-ignore-db=information_schema

binlog-ignore-db=mysql

Service mysql restart

L’ultimo comando impartito è, come vedete, il riavvio del servizio mysql. 

Configurazione Master-Slave: MASTER

Una volta riavviato il servizio bisogna entrare, creare un account per la replica, quindi collegarsi a MySQL e dare l’accesso in replica al server slave:

GRANT REPLICATION SLAVE ON *.* TO 'replication'@'%' IDENTIFIED BY 'webinar’;

FLUSH PRIVILEGES;

Show master status;

L’ultimo comando è necessario perché restituisce il nome, ma soprattutto la posizione del file di log.

Il risultato è una schermata tipo quella proposta nell’immagine seguente; salviamo questi dati perchè ci serviranno per avviare la replica. Sono importanti soprattutto quando andremo a ripristinare una replica che si è fermata o andiamo a creare una rete di un database che è già in uso.

Per capire questo pensate che se stiamo installando un mySQL pulito che non stiamo ancora usando, installiamo il master e lo slave e li configuriamo, nel momento in cui andiamo a creare un nuovo database sul master e lo popoliamo, automaticamente viene creato e popolato sullo slave: non bisogna andare a crearlo.

Ma se prendiamo un mySQL di produzione che già stiamo usando e andiamo ad abilitare la replica, dobbiamo fare un backup e restore del database per poi andarlo ad allineare, però il sistema deve sapere da dove si deve allineare, qual è il dato al quale si è fermato. Ecco perché occorre impartire il comando Show master status: e andare a segnare la posizione, una volta nota la quale possiamo andare a creare il backup del database

Configurazione server Slave

Nello slave la configurazione è analoga a quella vista per il master:

nano /etc/mysql/mysql.conf.d/mysqld.cnf

server-id = 1523612659

log_bin = mysql-bin.log

expire_logs_days = 5

service mysql restart

Quindi dobbiamo definire l’ID dello slave, che deve essere superiore a quello del master, impostare il solito percorso di rete dei log e definire i giorni per cui devono essere conservati i file.

Ora dobbiamo dire allo slave chi è il master e garantirne l’accesso, indicando il file di log che

abbiamo recuperato prima con il comando Show master Status e la relativa posizione.

Mysql –u root –p

CHANGE MASTER TO MASTER_HOST='10.134.252.210',MASTER_USER='replication', MASTER_PASSWORD='webinar',

MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS= 588;

START SLAVE;

SHOW SLAVE STATUS\G

Quindi ci colleghiamo, diamo il comando Change Master to Master Host, specifichiamo qual è l’host master, quali sono i dati di accesso dell’account di replica che abbiamo creato prima e, come vedete, poi passiamo qual è il Log File da utilizzare e qual è la Master Log Position (588). Da qui andiamo a recuperare qual è il file di log e qual è la posizione.

Fatto questo avviamo lo slave e impartiamo il comando Show Slave Status/G, cosicché il server si avvia e va allineandosi alle posizioni del nostro sistema.

Per verificare se tutto sarà stato allineato, sarà utile fare delle query per andare a vedere se il dato è viene riportato per intero e i dati sono correttamente allineati. 

Se stiamo iniziando a fare la replica di un DB già esistente sul master, dobbiamo fare un dump di

quel DB e ripristinarlo poi sul server SLAVE, tutti i nuovi DB verranno in automatico creati anche

sullo SLAVE.

Porte firewall per la replica geografica in mySQL

Se dobbiamo fare una replica geografica nel caso di mySQL, abbiamo bisogno di abilitare le porte per consentire le connessioni. Per consentire le repliche di MySQ basta avere aperto la porta standard di MySQL, che è la 3306.

HIGH AVAILABILITY con Load Balancer

Un sistema ad alta affidabilità contempla generalmente più server su cui sono in esecuzione dei servizi, ad esempio dei web server, davanti ai quali è posto un bilanciatore di carico di rete.

In questo caso spiegheremo in che modo utilizzare convenientemente HAProxy come bilanciatore di carico capace di distribuire il carico di rete solo ai server che rispondono al sistema di monitoring integrato in HAProxy stesso.

Anche il nostro HAProxy va posto sotto HA e qui ci viene in aiuto keep-alived, con il quale possiamo condividere l’IP in modo virtuale e tiene sotto monitoring il server; in tal caso se riavviamo il server interverrà subito l’altro server.

Sinora abbiamo parlato di avere più database, ma se davanti abbiamo una macchina sola e questa “va giù” tutto il discorso viene vanificato. Ecco perché è utile avere un load balancer che riconosce lo stato dei vari server e dirotta il traffico nel caso una non risponda.

L’immagine seguente riporta una tipica configurazione High Availability dove c’è una macchina che riceve le richieste e poi le smista sui server, i quali possono essere server web, server applicativi o database server.

Nel caso il load balancer -in questa evenienza ci riferiamo ad HAProxy- vada down, è comunque possibile mantenere l’operatività, perché si può mettere HAProxy in High Availability, ossia si vanno a prevedere due load balancer: uno primario e uno secondario. HAProxy è una macchina Linux che richiede poche risorse, in essa si installa Keep Alived, si effettua il floating IP, come vedete nell’immagine precedente.

Quindi chi entra arriva sull’IP condiviso e in realtà c’è quello primario attivo che smista le richieste agli application server che gli si trovano dietro; nel momento in cui riavviate il servizio HAProxy, si arresta il servizio, piuttosto che si verifica un problema sulla macchina in cui gira HAProxy, il floatin IP è praticamente immediato e si passa al Load Balancer secondario. La cosa è praticamente trasparente.

Attenzione che avendo fatto un keep-alive e quindi un Floating IP e basta, ogni modifica di configurazione fatta sull’HAProxy primario va applicata a mano sul secondario o tramite script o altri sistemi che tengono allineati i sottosistemi.

Installazione e configurazione HAProxy

L’installazione è molto semplice e per eseguirla possiamo passare tramite i repository secondaro o andare a cercare i pacchetti nei repository ufficiali dove, però, se utilizziamo il sistema operativo Ubuntu avremo a disposizione una vecchia versione (1.6.3) invece che la nuova 1.8.5. Il comando per installare il pacchetto è:

apt-get install haproxy

Oppure, in alternativa, è possibile utilizzare un repository differente inserendo i seguenti comandi:

apt-get install software-properties-common

add-apt-repository ppa:vbernat/haproxy-1.8

apt-get update

apt-get install haproxy

HAProxy ha un suo sistema di monitoring e un suo sito web dove accedere per andare a vedere le statistiche; da qui è possibile vedere cosa accade nella parte di front-end, i dati che sta ricevendo e che sta smistando sulla parte di back-end (quali server sono attivi e quanto traffico stanno facendo)

Con un HAProxy è possibile gestire più back-end e più front-end, quindi la porta 80, la porta 25 ecc. Potete quindi gestire tutte le connessioni TCP che passano.

Vediamo dunque un esempio di configurazione: in un primo momento configuriamo un webserver interno per vedere le statistiche di utilizzo di HAProxy e monitorare che i webserver del back-end siano raggiungibili.

listen haproxy-monitoring

bind *:80

mode http

stats enable

stats show-legends

stats refresh 5s

stats uri /

stats realm Haproxy\ Statistics

stats auth admin:admin

stats admin if TRUE

timeout connect 3500ms

timeout client 10800s

timeout server 10800s

Nella seconda parte della configurazione andiamo a configurare la nostra parte di front-end e di back-end.

frontend SMTP_25

bind *:25

mode tcp

no option http-server-close

timeout client 1m

log global

option tcplog

default_backend SMTP_25_BE

backend SMTP_25_BE

mode tcp

balance roundrobin

no option http-server-close

log global

option tcplog

timeout server 1m

timeout connect 5s

server smtp-rl1 10.150.252.130:10024 check send-proxy

server smtp-rl2 10.150.252.131:10024 check send-proxy

server smtp-rl3 10.150.252.132:10024 check send-proxy

Come vedete, possiamo gestire l’invio di e-mail sulla porta 25 (SMTP) che poi gira sugli altri server.

Testiamo adesso che la configurazione eseguita sia corretta, prima di applicarla, utilizzando il comando:

haproxy -c -V -f /etc/haproxy/haproxy.cfg

e, se non abbiamo riscontrato errori, possiamo riavviare il servizio:

systemctl restart haproxy

systemctl status haproxy

Quello che vedremo sullo schermo sarà del tipo:

Passiamo quindi all’interfaccia web di HAProxy, riportata nell’immagine seguente, dove vediamo nella sezione di front-end quante richiesta sta ricevendo e poi la parte di backend relativa ai server (sono in verde) a valle, nella quale è riportato quanto traffico hanno fatto, qual è l’ultima volta che sono stati interrogati ecc.

Da qui è possibile anche limitare la quantità di richieste gestite e dirette ai server a valle.

Ovviamente nella configurazione abbiamo fatto un check (Send Proxy): praticamente si fa il check su un servizio e se il servizio stesso non risponde, significa che il server su cui gira è down.

Notare che se non ci fosse la possibilità di supportare il comando Send Proxy da parte del server a valle di HAProxy, non sarebbe avere l’IP di partenza della richiesta che arriva al front-end e passa dal load Balancer per dirigersi al server destinatario. Per intendersi, senza il supporto al Send Proxy da parte del server che riceve da esso, vedendo il log tutti gli IP di origine sono quelli di HAProxy, pertanto in caso di attacco informatico o comunque di intrusione nella rete diverrebbe difficile capirne l’origine. Invece supportando Send Proxy, il server destinatario sa sempre l’IP di partenza del traffico dirottato dal Load balancer, perché HAProxy informa il server stesso del fatto che sta effettuando un Send Proxy e comunica l’IP originario.