Dat een verbing met SSL niet altijd veilig hoeft te zijn is wel aangetoond d.m.v. veiligheidsproblemen in sommige SSL varianten. Het is echter eenvoudig om NGINX te beveiligen tegen het stelen van cookies tijdens een SSL sessie. Meer info over BEAST
Pas de volgende parameters in de configuratie van NGINX aan:
ssl_ciphers RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
PS: Vergeet NGINX niet te herstarten na deze wijzingen.
Om een hogere beschikbaarheid te bieden van bijv. een web of databaseserver kan gekozen worden om heartbeat te gebruiken. Het idee erachter is simpel en het eenvoudigst uit te leggen aan de hand van een voorbeeld. We gaan uit van een clustertje van 2 servers die MySQL draaien met de bedoeling als 1 van de 2 servers uitvalt, de andere het automatisch overneemt. In deze documentatie die uit de praktij komt is uitgegaan van een eenvoudige opzet met 2 servers die via een aparte netwerkinterface het heartbeatsignaal versturen. Dit kan ook serieel gebeuren maar dat komt in de praktijk minder voor.
De bron/sourcebestanden en de documentatie zijn te vinden op http://www.linux-ha.org/wiki/Main_Page
Voor de meeste distributies is er wel een package beschikaar van heartbeat 3.x. In dit praktijkgeval werd gekozen om de van de source/broncode RPM packages te maken voor de twee RedHat Enterprise Linux 5 servers. Dit is, als voldaan is aan de verschillende dependencies, eenvoudig omdat er .spec files worden meegeleverd.
Er zijn drie source/broncode archives nodig: resource-agents, cluser-glue en heartbeat. Deze zijn te vinden op http://www.linux-ha.org/wiki/Downloads
Gegevens MySQL server 1:
Gegevens MySQL server 2
Als virtueel IP adres wordt 192.168.1.10 gebruikt.
De configuratie van hearbeat bestaat uit het configuren van /etc/ha.d/ha.cf, /etc/ha.d/haresources en /etc/ha.d/authkeys.
In dit bestand komt een sleutel te staan die gedeeld wordt over de nodes binnen het cluster en heeft het volgende formaat:
auth num
num algorithm secretWaarbij num een opvolgend nummer is, te beginnen bij 1. Het algoritme is meestal sha1 en secret is de daadwerkelijk sleutel. Deze sleutel kan worden aangemaakt met het onderstaande shell script:
( echo -ne "auth 1\n1 sha1 "; \ dd if=/dev/urandom bs=512 count=1 | openssl md5 ) > /etc/ha.d/authkeys chmod 0600 /etc/ha.d/authkeys
Hiermee wordt tevens aan een andere vereiste voldaan, het authkeys bestand mag alleen voor root leesbaar zijn en hieronder staat een voorbeeld de inhoud van de authkeys:
auth 1 1 sha1 29d72a23963e8350a65b78e8052678ef
logfacility local0 autojoin none keepalive 2 deadtime 15 ucast eth3 10.10.37.1 auto_failback on node dbserver01.mijndomein.nl node dbserver02.mijndomein.nl
Geeft aan hoe middels de syslog daemon gelogd wordt.
Er wordt door autojoin none voorkomen dat er automatisch naar nieuwe nodes voor het cluster wordt gezocht bij het opstarten van heartbeat. Dit versnelt het opstarten in met name kleinere clusteromgevingen.
De tijd in seconden dat een heartbeat signaal wordt verzonden.
De tijd in seconden voordat een node ‘dood’ verklaard wordt en het overfailen naar de andere node wordt gestart.
In deze omgeving is gekozen om middels ucast de aanwezigheid van de nodes te controleren. Een andere optie zou multicast (mcast) zijn. Indien,zoals in dit voorbeeld, er een apart VLAN voor heartbeat is opgezet kan ucast gebruikt worden.
Geeft aan met de optie on of off of heartbeat automatisch moet overfailen.
Definieert de nodes binnen het heartbeat cluster. Het is raadzaam de hostnamen op te nemen in /etc/hosts zodat deze ten alle tijde te resolven zijn en niet door eventuele nameserverproblemen het heartbeatproces verstoord.
dbserver01.mijndomein.nl 192.168.1.10 mysql
In deze file wordt aangegeven welke node de master is, wat het virtuele ipadres voor de buitenwereld is om een bepaalde service aan te bieden. In dit geval is dus de dbserver01 de primaire node met het virtuele ipadres 192.168.1.10 en wordt de service MySQL geclusterd. Dit staat los van hoe MySQL geinstalleerd is. Zodra er zich een overfail situatie voordoet wordt het virtuale ipdres op de primaire node down gebracht en wordt MySQL gestopt. De secundaire node zal dan na de periode die opgegeven is, het virtuele ipadres up brengen en MySQL starten. De data van MySQL werd in dit geval op een shared storage opgeslagen.
Als de configuratie op de primaire node afgerond is kunnen de nodes de noodzakelijke configuratiebestanden via ha_propagate worden gepushed. Deze tool in te vinden in /usr/lib/heartbeat/ha_propagate of /usr/lib64/heartbeat/ha_propagate. Middels scp (ssh) worden de nodes die in de /etc/ha.d/ha.cf zijn opgenomen geconfigureerd. In dit voorbeeld bestaat het cluster uit slechts twee nodes en is ha_propagate misschien niet nodig maar als een cluster uit vele nodes bestaat is deze manier aan te raden.
Opmerking: Wel is het noodzakelijk om per node het ucast/mcast ipadres aan te passen en eventueel de gebruikte interface voor het heartbeat signaal.