1) Préconisations

1.1) Système

Les noyaux linux postérieurs à la version 2.2.14 intègrent les fonctionnalités LVS, si vous n’êtes pas à ce niveau, vous devrez patcher le kernel avec le module “IPVS” prévu pour votre distribition.

Généralement, les serveurs LVS sont doublés, en mode FailOver, et supervisés par un module chargé de faire la bascule du primaire vers le secondaire en cas de défaillance du primaire, en effet, rien ne sert par exemple d’avoir une ferme de serveurs Web si votre LVS ne fonctionne plus et que personne ne peut plus y accéder… Pour cela, il existe plusieurs solutions classiques telles que HeartBeat ou KeepAlived. Dans notre exemple, nous utiliserons KeepAlived.

Dans nos tests, nous avons utilisé une openSuSE 11.4 64bits (kernel 2.6.37) et qui intègre donc la fonctionnalité IPVS. Les serveurs LVS possèdent chacun trois cartes ethernet dont un couple est configuré pour le réseau de production en bonding et la troisième carte sert pour la gestion du FailOver du serveur LVS (protocole VRRP) avec l’utilitaire KeepAlived.

Téléchargements :

- OpenSuSE : http://software.opensuse.org/114/fr

- Doc LVS : http://www.linuxvirtualserver.org/Documents.html

- IPVS (si kernel < 2.2.14) : http://rpm.pbone.net/index.php3?simple=1&stat=3&search=ipvs

- KeepAlived (optionnel) : http://www.keepalived.org/software/keepalived-1.2.2.tar.gz

1.2) Matériel

Evidement plus votre machine est puissante mieux cela sera, cependant, il ne faut pas perdre à l’esprit que votre solution LVS se comportera à priori comme un switch (niveau 4 du modèle ISO), même si certains “patchs” peuvent l’amener à interagir au niveau 7.  A ce titre les interfaces réseaux doivent être le premier niveau de qualité, la CPU (nombre de processeurs / coeurs) le deuxième niveau.

Le premier travail d’un serveur LVS va consister en un routage, d’une adresse IP (adresse virtuelle, ou “IPV”) et un port connu du grand public et la redirection d’un flux réseau qui sera transmis, en fonction de la “charge” estimée sur les serveurs de la ferme et de sa disponibilité, vers le serveur le plus “disponible” (le moins chargé). L’analyse de la charge d’un serveur dépend d’un algorithme et demande donc de la CPU, mais la notion primaire demeure celle de la charge réseau, il vous appartient de l’estimer correctement.

Nous verrons qu’il existe plusieurs façons de déterminer la charge d’un serveur, de plus ou moins pertinentes, sachant que plus l’algorithme de détermination de charge est complexe plus vos serveurs LVS nécessiteront de la CPU, ne l’oubliez pas.

Dans le meilleur des mondes, des cartes Gb sur vos serveurs LVS ainsi que des machines avec un maximum de coeurs selon l’avis et le budget de votre DSI

2) Configuration de LVS

2.1) LVS : un “switch” intelligent

Les fonctionalités de base de LVS sont de répondre à un client IP qui cherche à joindre un serveur sur une IP “<ip>” en dispatchant cette demande sur divers serveurs identiques et pouvant répondre à la demande. Les protocoles possibles sont tous ceux que TCP/IP ou UDP/IP peuvent proposer. La persistance de session est ainsi assurée par IPVS en fonction de l’adresse IP de l’émetteur de la demande (niveau 4), en d’autre termes, un internaute qui est dirigé vers le serveur n°X d’une ferme web à son premier accès sera de nouveau redirigé vers le même serveur lors des accès suivants grâce à LVS.

Nous allons donc indiquer à LVS, pour chaque IPV à gérer, quels sont les serveurs rééls et composant la ferme en face de cette adresse. Nous indiquerons de plus à LVS la méthode que celui-ci devra utiliser pour “estimer” la charge d’un serveur.

Le serveur LVS “primaire” de notre cluster de LVS en FailOver se nomme un DIRECTOR.

2.2) Indiquer l’IPV de votre ferme à votre serveur LVS

Prenons le cas d’une ferme Web Classique basée sur 2 LVS en FailOver et 3 serveurs réels.

Il existe donc dans notre exemple 3 serveurs rééls, chacun avec une adresse IP réelle @1, @2 et @3. Cependant, hors de question de donner cette information aux internautes, pour eux, un seul serveur existe d’un point de vue extérieur avec une seule adresse IP @v, c’est l’adresse IP Virtuelle de votre ferme Web , ou IPV.

Cette IPV est (au moins) fixée au sein du serveur LVS grâce à l’utilitaire ipvsadm et les paquets arriveront donc en premier sur cette adresse avant d’être dispatchée sur l’un ou l’autre des serveurs réels.

Si l’adresse IP “virtuelle” pour joindre votre ferme web est 192.168.1.10, il faudra utiliser sur votre serveur LVS la commande suivante:

shell> ifconfig eth0:v0 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255 up

Il faudra ensuite autoriser Linux à faire transiter les paquets d’une interface à d’autres interfaces (routage de l’IPV vers les IPR – ip réelles), il faut pour cela activer l’ip forwarding. Il faut également calibrer vos serveurs LVS pour qu’ils se comportent d’une certaine façon face au protocole ARP. La raison technique est décrite dans cet article, cela consiste grossièrement à éviter que vos serveurs LVS n’interceptent des paquets qui sont en fait destinés initialement aux serveurs réels.

Voici le contenu de /etc/sysctl.conf (à minima, à adapter selon votre configuration) :

net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
net.ipv4.conf.lo.forwarding=0
net.ipv4.conf.lo.arp_ignore=1
net.ipv4.conf.lo.arp_announce=2
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

2.2) ipvsadm

C’est le nom de l’utilitaire qui va (généralement) nous servir à configurer dynamiquement notre serveur LVS dynamiquement, il est apporté par les distributions aux kernels > 2.2.14, et sera apporté par les rpm ipvs que vous aurez pris soin d’installer dans la négative. Sans cet utilitaire, vous ne pouvez pas configurer votre serveur LVS. Les utilitaires de configuration automatique tels que KeepAlived se basent eux aussi sur ipvsadm.

2.2.1) Indiquer la présence d’une IPV à votre serveur LVS:

shell> ipvsadm --add-service --tcp-service 192.168.1.10:80 --scheduler rr

Ceci signifie que votre serveur LVS va accepter les paquets à destination de 192.168.1.10 sur le port 80 pour les transmettre aux serveurs réels que nous allons décrire ci-dessous.

L’algorithme de répartition de charge ici est “–scheduler rr”, c’est à dire du Round Robin (Un pour Un). Nous verrons en 2.4 les différents algorithmes disponibles.

2.2.2) Indiquer la présence des 3 serveurs réels à LVS :

shell> ipvsadm --add-server --tcp-service  192.168.1.10:80 --real-server 192.168.1.1:80 --masquerading --weight 10
shell> ipvsadm --add-server --tcp-service  192.168.1.10:80 --real-server 192.168.1.2:80 --masquerading --weight 10
shell> ipvsadm --add-server --tcp-service  192.168.1.10:80 --real-server 192.168.1.3:80 --masquerading --weight 10

Explications:

• –tcp-service: les paquets transmis au serveur réel seront ceux qui arrivent sur l’IPV 192.168.1.10 et le port 80 du serveur LVS
• –real-server: nos serveurs réels ont les @ip 192.168.1.1, 192.168.1.2 et 192.168.1.3, ils écoutent sur le port 80
• –masquerading: le Director va utiliser le protocole NAT pour faire transiter les flux TCP avec les serveurs réels (voir 2.3.1)
• –weight: notion de poids (de priorité pour le LoadBalancing)

Comme vous le découvrirez en 2.2.1) et en 2.2.2) , la route par défaut peut varier selon les configiurations, il se peut quand (comme dans 2.2.1) vous soyez obligé d’utiliser l’adresse du serveur LVS alors que dans d’autres cas (voir 2.2.2) vous deviez indiquer l’adresse IP de votre routeur / firewall.

2.2.3) Vérifier la prise en compte des ordres tables ipvs

shell> ipvsadm --list

  IP Virtual Server version 1.2.1 (size=4096)

  Prot LocalAddress:Port Scheduler Flags

    -> RemoteAddress:Port           Forward Weight ActiveConn InActConn

  TCP  192.168.1.10:http rr persistent 360

    -> 192.168.1.1:http              Route   1      2          0

    -> 192.168.1.2:http              Route   1      0          0

    -> 192.168.1.3:http              Route   1      0          0

  TCP  192.168.1.10:https rr persistent 360

    -> 192.168.1.1:https              Route   1      0          0

    -> 192.168.1.2:https              Route   1      0          0

    -> 192.168.1.3:https              Route   1      0          0

Nous voyons dans cet exemple que les paquets qui arriveront sur l’adresse ip virtuelle 192.168.1.10 sur le port 80 (http) seront redirigés selon la règle du Round Robin (rr) sur les serveurs de la ferme, l’un après l’autre.

Remarque: Nous avons refait les mêmes définition avec le port 443 (https) pour ls connexions sécurisées de notre fermer de serveurs Web.

Remarque: A l’instant où nous passons la commande “ipvsadm -l” sur notre Director, nous constatons que 2 sessions sont établies vers le serveur physique 192.168.1.1.

2.3) Routage direct (DR) ou Translations d’adresses (NAT)

Il existe principalement deux méthodes pour établir un dialogue entre un serveur LVS et un serveur d’une ferme dont il est chargé d’assurer la balance de charge.

Une troisième méthode moins usitée est celle de l’établissement de tunnel entre les serveurs LVS et les serveurs réels (TUN), cette méthode n’est pas décrite dans cet article car très peu usitée, cf DOC en cas de besoin.

2.3.1) NAT (Network Address Translation)

Le mode NAT, le plus classique et le plus simple à mettre en oeuvre consiste à translater l’adresse IP cible (ipv) d’un paquet reçu par l’adresse réelle du serveur choisi par l’algorithme d’analyse de charge.

C’est le même principe que l’en rencontre dans tous les routeurs d’entreprise pur que les employés puissent sortir sur l’internet, le même principe que pour votre InternetBox personelle :

Il est à noter que, en plus de demander au serveur LVS de gérer la balance de charge, nous allons lui demander en permanence de retoucher les trames TCP/IP afin d’effectuer la translation de la VIP vers toutes les adresses réelles, ce qui peut s’avérer gourmand en CPU, à surveiller de près.

Remarque: Dans le cas où vous opteriez pour le NAT, il ne faudra pas oublier d’indiquer à tous les serveurs de votre ferme que la route par défaut est le Director, à savoir la patte LAN de votre serveur LVS.

Remarque: Un exemple d’implémentation de serveur LVS avec le protocole NAT est décrit dans l’exemple ci-dessus en 2.2.2).

2.3.2) DR (Direct Routing)

2.3.2.a) Présentation

Le mode DR, comme son nom le suggère, ne va pas utiliser de translation d’adresse mais va faire suivre les paquets directement au serveur désigné comme idéal par l’algorithme d’analyse de charge. Une fois le paque traité par le serveur réel, celui-ci ne va pas renvoyer la réponse au serveur LVS qui n’en a que faire mais va directement la transmettre à sa gateway comme le montre le schéma ci dessous :

On allège ainsi le LVS de la gestion de tous les flux de retour et de la gestion des translations d’adresses, c’est largement plus performant et donc c’est l’option qui doit être considérée en premier.

Pour indiquer à votre serveur LVS qu’un serveur doit répondre au protocole DR, vous devrez l’indiquer à ipvsadm avec la commande:

shell> ipvsadm --add-server --tcp-service  192.168.1.10:80 --real-server 192.168.1.1:80 --gatewaying --weight 10
shell> ipvsadm --add-server --tcp-service  192.168.1.10:80 --real-server 192.168.1.2:80 --gatewaying --weight 10
shell> ipvsadm --add-server --tcp-service  192.168.1.10:80 --real-server 192.168.1.3:80 --gatewaying --weight 10

2.2.2.b) Problématique du routage

Nous sommes donc dans ce cas là dans une problématique de routage pur. Le serveur LVS va router le paquet ayant pour adresse cible l’IPV vers un des serveurs rééls, c’est là que les ennuis commencent : étant donné que l’adresse cible est l’IPV et que le serveur réel possède une autre adresse ip, l’adresse IP réelle,il va en toute logique refuser le paquet. Pour pallier à ce problème, nous allons simplement rajouter, sur tous les serveurs rééls de la ferme, une adresse ip secondaire (alias) qui sera l’IPV. Attention, il ne faut surtout pas rajouter cet alias à une carte ethernet du serveur car auquel cas, des trames sortiront sur le réseau (brodcast) de tous les serveurs avec la même IPV, vous aurez alors des conflits d’IP sur tout le média => catastrophe, plus rien ne fonctionnera.

Pour pallier à ce problème, il suffit d’ajouter l’alias à la loopback qui ne s’annonce pas sur les réseaux par définition mais qui permettra à un serveur réel de considérer que un paque à destination de l’IPV est bien pour lui.

Généralement, il suffit d’aller modifier le fichier /etc/sysconfig/network/ifcfg-lo tel que :

#DESC de l'IPV de votre ferme :
IPADDR_0=192.168.1.10                  
NETMASK_0=255.255.255.255
NETWORK_0=192.168.1.0
BROADCAST_0=192.168.1.255
#----------------------------------
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
BROADCAST=127.255.255.255
STARTMODE=onboot
USERCONTROL=no
FIREWALL=no

Remarque: Dans le cas où vous opteriez pour le DR, il ne faudra pas oublier d’indiquer à tous les serveurs de votre ferme que la route par défaut est l’adresse IP de la patte interne de votre routeur / firewall.

2.3) Algorithmes d’analyse de charge (RR, WRR, …)

Un algorithme de répartition de charge est à indiquer à votre serveur LVS lorsque vous créez une IPV (un cluster) grâce au commutateur –scheduller (voir 2.2.1))

Les algorithmes d’analyse de répartition de charge des IPVS sont larges, en voici un bref descriptif des plus usités:

D’autres algorithmes plus rares d’utilisation existent, consulter la doc pour plus d’informations

Rappel: le protocole d’analyse de charge est à utiliser avec ipvsadm lors de la définition d’un Cluster sur le Director et en fin de commande (voir 2.2.1)

2.4) LVS /FailOver :

Evidement, si votre serveur de répartition de charge ne répond plus, quelle qu’en soit la raison, inutile d’avoir une ferme de site web en dessous si votre solution de HA s’arrête ici. Pour pallier à cela, il vous faut installer une couche supplémentaire qui gère cette notion de Haute Disponibilité et la possibilité de démarrer rapidement dynamiquement un serveur secondaire si le primaire ne répond plus. Deux grandes voies se dessinent : HeartBeat et KeepAlived. Pour des raisons purement subjectives nous avons choisi KeepAlived alors que HeartBeart rempli strictement le même rôle… Il fallait bien en choisir un

KeepAlived apporte la configuration automatique du serveur LVS, et oui, tout ce que vous avez lu est à mettre à la poubelle, c’était pour tester votre attention (envoyer les insultes à contact@edfgdf.fr svp, c’est très tendance).

En fait KeepAlived apporte la configuration automatique du serveur et la gestion d’un serveur en FailOver de votre Director, ce qui vous permet aisément d’assurer totalement la haute disponibilité de vos services TCP/IP.

2.4.1) Téléchargement

• KeepAlived  : http://www.keepalived.org/software/keepalived-1.2.2.tar.gz

2.4.2) Installation

Décompressez l’archive dans un répertoire temporaire :

shell> cd /datas/downloads/
shell> tar -zxvf keepalived-1.2.2.tar.gz

Compilez les fichiers objets en indiquant le repertoire d’installation avec

shell> ./configure --prefix=/data/keepAlived/

Vous pouvez rencontrer des erreurs à ce statde, elle ne concernent généralement que des packages manquant mais nécessaires dans votre distribution, ne les négilgez pas au risque de dysfonctionnements ultérieurs.

Linkez et terminez votre installation par

shell> make

...

shell> make install

...

Voilà, KeepAlived est installé …

L’install vous amène les fichiers suivants:

• keepalived et son fichier de conf keepalived.conf (placez le de preference dans /etc/keepalived/)
• ./rc.d/keepalied pour le fichier d’init de init.d (places le dans /etc/init.d/rc3.d et créez les liens)
• genhash (un utilitaire md5 pour keepalived afin de vérifier le contenu de certains flux retournés)

A vous de disposer ces fichiers dans vos répertoires préférés pour que tout fonctionne bien.

2.4.3) Utilisation

Tout se trouve dans la configuration (élémentaire) de /etc/keepalived/keepalived.conf.

2.4.3.a) Configuration globales

Les configurations globales de keepAlived consistent principalement en la définition d’un nom (ID) pour votre serveur LVS Director et quelques informations pour envoyer des emails d’alertes tel que :

global_defs {
   notification_email {
     admin1@domaine.com admin2@domaine.com
   }
   notification_email_from director-1@domaine.com
   smtp_server smtp.domaine.com
   smtp_connect_timeout 30
   router_id LVS1
}

routeur_id doit être unique sur les différents serveurs LVS que vous allez configurer et qui vont composer votre cluster en FailOver. Les autres paramètres sont triviaux.

2.4.3.b) Configuration du protocole de surveillance du FailOver (VRRP)

vrrp_instance VRRP1 {
    state MASTER
    interface eth0
    virtual_router_id 50
    priority 50
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 6841665145
    }
    virtual_ipaddress {
        192.168.1.10
    }
}

• state: MASTER ou BACKUP, il définit le serveur primaire (actif) de vos serveurs LVS, c’est grâce à cette information que KeepAlived saura basculer sur un serveur esclave si le master ne répond plus.
• interface: quelle est l’interface réseau dédiée à la surveillance du cluster en VRRP. On évite de positionner l’interface de production afin de ne pas perturber les temps de réponse et de déclencher une bascule à tort.
• virtual_router_id: un numéro UNIQUE pour l’ensemble de vos serveurs LVS
• priority: Désirez-vous basculer prioritairement vers un serveur plustôt qu’au autre en cas d’echec VRRP? Si non, mettez la même valeur dans tous les serveurs LVS.
• authentication: un login / pass pour que les serveurs dialogue en VRRP de façon sécurisée entre eux (il doit être identique de partout évidement…)
• virtual_ipadress: le nom est assez parlant, l’IPV ou les IPV de votre serveur LVS

virtual_server 192.168.1.10 80 {

        delay_loop 10
        lb_algo RR
        lb_kind DR
        persistence_timeout 360
        protocol TCP

        real_server 192.168.1.1 80 {
                weight 1
		TCP_CHECK {
			connect_port    80
			connect_timeout 3
		}
        }

        real_server 192.168.1.2 80 {
                weight 1
		TCP_CHECK {
			connect_port    80
			connect_timeout 3
		}
        }

        real_server 192.168.1.3 80 {
                weight 1
		TCP_CHECK {
			connect_port    80
			connect_timeout 3
		}
        }
}

Voici un bref descriptif de ces paramètres:

• virtual_server: l’adresse IP Virtuelle de votre serveur virtuel et son port d’écoute
  • delay loop: intervalle en secondes entre les différents tests de présence des serveurs réels
  • protocol: ici on utilise TCP (on peut aussi utiliser UDP dans certains cas)
  • lb_algo: algorithme de LoadBalancing (rr, wrr, dr, wdrr, … : voir 2.4))
  • lb_kind: méthode de routage (NAT ou DR, voir 2.3))
  • real_server: définition d’un serveur réél dans cette ferme, adresse réelle et port d’écoute
    • weight: poids du serveur pour load balancing
    • tcp_check: on va régulièrement vérifier que le port 80 de ce serveur réel répond, et, au bout de 3 secondes en echec, on considère que le serveur est mort, le serveur LVS va alors l’éliminer dynamiquement de la ferme jusqu’à ce que celui-ci réponde de nouveau.

Exemple HTTP_GET:

C’est l’algorithme MD5 qui va nous permettre de vérifier que le contenu d’une page ne varie pas et est réglementaire. Prenez par exemple la page /test.php de votre site web, faite lui faire une connexion à votre database, une opération élémentaire en php afin que le résultat présente par exemple “TRUE” en cas de réussite ou “FALSE” en cas d’echec.

Utilisez l’utilitaire genhash pour calculer le hash MD5 de ce retour http avec la commande suivante :

shell> genhash -s 192.168.1.1 -p 80 -u /test.php

shell> 53f43f0f4f1c99c10230f5f0758915f1

Ici, la clé MD5 du résultat de cette page test est donc “53f43f0f4f1c99c10230f5f0758915f1″. Il faut que ce fichier soit évidement sur chaque serveur réel de votre ferme.

Vous devez donc simplement remplacer la clause TCP_CHECK (voir 2.4.3.c)) par celle-ci:

HTTP_GET {

		url {

		     path /test.php

		     digest 53f43f0f4f1c99c10230f5f0758915f1

	}

        connect_timeout 3

        nb_get_retry 3

        delay_before_retry 2

}

Le descriptif des paramètre est trivial … On va essayer d’aspirer http://192.168.1.1:80/test.php avec un timeout de 3 secondes et nous allons réessayer 3 fois par intevalle de 2 secondes avant de considérer un echec. Une réussite est vraie si le checksum MD5 du contenu retourné est conforme à la clé indiqué par “digest”.

Le test GET_HTTPS se configure de la même façon.

Exemple MISC_CHECK:

Imaginez que l’indication de conne santé d’un serveur réel dépende du déclanchement d’un script (qui doit retourner 1 en cas de bon fonctionnement et 0 en cas d’echec), alors la clause HTTP_CHECK sera replacée par :

MISC_CHECK {

	misc_path /data/scripts/mon_script.sh param1 param2

}

Assez simple à priori

2.4.4) Gestion d’un serveur LVS secondaire (“backup”) :

Dans le cadre d’un cluster en FailOver, il faut au moins un deuxième serveur LVS, sachant que vous pouvez sécuriser l’ensemble à plus que 2 serveurs dans le cluster (parano quand tu nous tiens …).

Pour ce faire, rien d’extraordinaire, il suffit simplenent de disposer d’une deuxième serveur à l’identique en configuration du Director et d’apporter les modifications suivantes au fichier /etc/keepalived/keepalived.conf :

vrrp_instance VRRP2 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 50
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 6841665145
    }
    virtual_ipaddress {
        192.168.1.10
    }
}

3) Utilisation de LVS et monitoring

• Deux sockets maximum par serveur
• Pas de DataGuard autorisé
• Pas d’Oracle Streams autorisé (même si ce n’est pas vraiment un cadeau…)
• Pas de sauvegarde incrémentales Rman possibles
• Pas de flashback database possible
• Pas de partitionnement autorisé
• Pas de … pas de … etc  (et il en reste …)

Autrement dit, la pluspart des innovations apportées en 10g sont interdites en version “standard”. Au delà de ces nombreuses limitations (non exhaustives), Oracle vous interdit de plus l’achat et/ou l’utilisation des Options Pack(qui sont pourtant installés par défaut lorsque vous installez une version “standard” ce qui est limite illégal de la part d’Oracle) , à savoir :

• Diagnostick Pack
• Tunnig Pack
• Configuration Pak

Autrement dit, la DBConsole ne vous sert à quasiment à  ”rien“, l’onglet “Performances” est grisé, et vous devez, comme toute version antérieure à 10g, confectionner vous même tous les outils de surveillance…

Pour pallier à ce manque, il existe d’autres solutions, du moins en terme de monitoring et de l’analyse des performances de votre database, de tunning. Nous allons nous intéresser dans cet article au remplacement des Packs Oracle “Diagnostic” et “Tunning” pour lesquels d’exellentes alternatives existent, notamment “IGNITE for Oracle” de la société Confio.

1) Introduction:

Vous aurez malheureusement le loisir de constater que ce logiciel est loin d’être gratuit mais il constitue malgré tout une économie énorme comparée au prix de l’Entreprise Oracle selon votre configuration matérielle.

Le logiciel s’installe avec une facilité déconcertante. Celui-ci est basé sur un référentiel stoqué dans une database Oracle (pas celle qu’il faut surveiller évidement) et d’un accès aux vues systèmes de la database à surveiller afin de stoquer régulièrement l’état de l’ensemble des objets de l’instance.

Remarque: Ignite a une très grande possibilité d’historisation des données, de fabrication de report, etc, et vous permettra rapidement de fournir les éléments nécessaires dont les développeurs auront besoin pour corriger un problème de performance par exemple.

Ignite est joignable par l’intermédiaire d’un site web qui vous permettra d’observer l’activité de votre database en direct ou sur des périodes données.

Afin de rendre totalement indépendante la prise de mesure de l’état de la machine qui héberge votre database à surveiller, nous allons installer le référentiel Ignite (un simple schéma Oracle) sur une autre database située sur une autre machine que la machine de production. Ainsi, même en cas de grave problème sur la machine de production, vous pourrez tout de même interroger Ignite.

2) Périmètre

2.1) Introduction:

Dans notre exemple, la machine Oracle de production est une machine physique de 64G de RAM et 12 cores, c’est en fonction de cette “puissance” que vous paierez plus ou moins cher votre licence Ignite, un peu à la sauce Oracle, mais en moins cher évidement…

Pour ne pas rajouter au coût, nous avons choisi d’installer le produit sur une openSuSE 11.3 (32bits) qui exploitera un référentiel basé sur ce même OS à travers un Oracle XE 10gR2. Le tout tournera sous une VM installée sur le serveur de votre choix (des solutiçons de virtualisations de tout niveau existent maintenant dans toutes les entreprises), cette solution ne coûtera donc pas un sous de plus que le prix du produit lui même.

2.2) Téléchargements:

• openSuSE 11.3 / 32b: http://software.opensuse.org/113/fr
• oraRun: http://ftp.novell.com/partners/oracle/sles-10/orarun.rpm
• Oracle XE 10gR2: http://www.oracle.com/technetwork/database/express-edition/downloads/102xelinsoft-102048.html
• Ignite: http://www.confio.com/English/Products/Ignite_for_Oracle.php

Donc : l’OS + Oracle Express + le produit, c’est tout !

Remarque: Oracle XE, de par ses limitations, vous impose une limitation à 1 core et 1024M de RAM pour calibrer votre VM, c’est pour cela que il n’existe pas de version 64bits, n’installez donc pas un OS 64 bits, vous ne rencontrerez que des problèmes inutiles…

3) Installation & configuration

3.1) Installation de OpenSuSE 11.3 32b

L’installation de l’openSuSE 11.3 ne nécessite strictement aucune compétence particulière, suivez l’assistant d’installation qui vous guidera de façon parfaite.

Une petite recommandation sur le partitionnement cependant:

/                <= 6Gb:  largement suffisant pour la racine (n'installez rien de superflu)
/var/log         <= 2Gb:  pour ne pas géner les applications en cas de logging excessif
/usr/lib/oracle  <= 3Gb:  par défaut le répertoire d'install de Oracle XE
/datas           <= 5Gb:  vos archives (max 1gb) et votre database (max 4gb en XE)

3.2) Installation de “OraRUN”

Ce package disponible pour les SLESS et les openSuSE est optionnel mais est bien pratique, il vous paramètrera par défaut toutes les préconisations Oracle liées à votre OS, inutile d’aller mettre les mains dans sysctl.conf, etc.

Vous pouvez ne pas l’installer et configurer vous mêmes les prérequis, à vous de voir.

> rpm -ivh /datas/downloads/orarun.rpm
> chkconfig 35 oracle
> rcoracle start

3.3) Installation de Oracle XE

Si vous n’avez pas installé OraRun comme indiqué précédement:

a – Créez un user “oracle” ayant pour home dir “/home/oracle” et appartenant aux deux groupes à créer également que sont “dba” et “oinstall“.

b – Affectez le user oracle et le groupe dba à /home/oracle.

c – editez le fichier /etc/profile et ajoutez à la fin les lignes suivantes:

export ORACLE_BASE=/usr/lib/oracle
export ORACLE_HOME=$ORACLE_BASE/xe/app/oracle/product/10.2.0/server
export ORACLE_SID=XE

export PATH=$PATH://usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin

Installez la version téléchargée de XE telle avec :

> rpm -ivh /datas/downloads/oracle-xe-10.2.0.1-1.0.i386.rpm
> ...
> /etc/init.d/oracle-xe  configure
> ... (laissez toutes les options par défaut)
> /etc/init.d/oracle-xe  start

Vérifiez que votre database est correctement installée et que votre instance est disponible :

> su  -  oracle
> [oracle] : sqlplus  /  as sysdba
> SQL*Plus: Release 10.2.0.1.0 - Production on Wed Mar 2 15:21:00 2011
> Copyright (c) 1982, 2005, Oracle.  All rights reserved.
> Connected to:
> Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
> SQL> select INSTANCE_NAME, DATABASE_STATUS from v$instance;
> 
> INSTANCE_NAME    DATABASE_STATUS
> ---------------- -----------------
> XE               ACTIVE

3.4) Installation de Ignite

3.4.1) Installation du web server IGNITE

L’installation des binaires Ignite ne pose aucun problème, il faut simplement les exécuter tel que et accepter (presque) toutes les options par défaut, sauf peut être celle du répertoire de destination…  :

cd /datas/downloads
tar -xvf ignite_pi_tf_8_1_118.tar
chmod +x ./ignite_pi_tf_8_1_118/ignite_pi_tf_8_1_118_installer.sh
./ignite_pi_tf_8_1_118_installer.sh

Verifying archive integrity... All good.

Uncompressing Ignite PI 8.0.110 installation files.........

Before installing and running Ignite PI, you must agree to the following

software license agreement (EULA).  Press [enter] to view the license...

. . . . . 

Do you agree with the license? [y/n]:y

Searching for java executable... This may take a few minutes, please be patient.

Found java executable at [/usr/lib/jvm/jre/bin/java].

Please note the following before proceeding:

Ignite PI is a web server.  You should install Ignite PI on a server that:

   - has network connectivity to the Repository and the monitored databases, and

   - is available at all times (a laptop might not be a good choice), and

    - is not running applications where performance is critical.

Proceed with installation? [Y/n]:y

This script will extract Ignite PI into a directory of your choosing.

The directory must already exist and must be writable by the current user.

Ignite PI will be extracted into its own version-specific directory under

the directory you enter below.  For example, if you enter "/home/ignite"

as the destination directory, Ignite PI will be extracted into the directory

"/home/ignite/pi_8_0_110".

Enter destination directory for Ignite PI [/datas/downloads]: /datas/ignite

Extracting Ignite PI to directory [/datas/ignite].......................................................................done.

Please view the readme.txt for startup and upgrade instructions.  The readme

will explain how to get Ignite PI running.  Once it is running, an Ignite PI

wizard will walk you through creating a Repository and monitoring database

instances. The readme.txt is located at: /datas/ignite/pi_8_0_110/readme.txt

Would you like to view the readme.txt now? [Y/n]:n

Ignite PI installation complete.

Ensuite si tout va bien, vous devrez démarrer le démon http IGNITE avec la commande :

> nohup   /data/ingite/pi_8_0_110/startup.sh   &

Vérifiez que le fichier /data/ignite/pi_8_0_110/nohup.out se termine bien par la phrase “Exiting script after webserver launched”, c’est que tout se passe bien pour le moment: un démon http écoute sur le port 8123, vérifiez par sécurité en exécutant la commande :

netstat -len | grep :8123

Si ceci est ok, vous pouvez utiliser votre navigateur web préféré pour commencer à configurer le référentiel Ignite en vous connectant sur “http://<ip_du_serveur_ignite>:8123“, vous verrez alors les écrans suivants apparaitres et à valider :

a) Veuillez “valider” votre intention de créer un repository pour les futures mesures:

b) Validez vous vous désirez créer ce repository dans une base Oracle:

c) Indiquez les paramètres nécessaires pour se connecter à la database Oracle qui contiendra le repository (ORACLE_SID, ip du serveur, port du listener) ainsi que le password du user “system” de cette database (et pas le pass du users “sys”!) :

d) Entrez un USERNAME / password  pour le schéma du repository :

e) Dans quel TableSpace le repository doit-il être stoqué ? (et quel est son tbs temporaire?) :

f) Voici un récapitulatif de vos choix, lise le avec soin et validez pour passer à la suite :

g) Vérifiez que tout s’est bien passé en parcourant la log et en validant que “Respository has been created”, sinon, inutile d’aller plus loin et trouvez le problème (et la solution )

Cliquez ensuite sur “Register database to monitor” pour configurer la database à surveiller.

h) Dans notre cas, évidement, sélectionnez “Oracle” comme type de database, puis continuez :

i) Définissez l’ensemble des paramètres nécessaires pour accèder à l’instance à monitorer (méthode de connexion : ici EazyConnect, hostname et port (1521) puis login / password de DBA (pas le user “sys” par sécurité) :

Puis cliquez sur “Next”…

j) Il faut, pour monitorer la database cible, créer un use Oracle sur celle ci, pour cela, il faudra donc préciser le tablespace par défaut du user (nous vous recommendaons de créer un tb spécifique pour ce schéma afin de ne pas géner les autres users de production de la database) ainsi que son tablespace temporaire (le tbs temp standard suffit) :

Cliquez sur “Next” !!

k) Il faut ensuite donner le mot de passe du user sys de votre database à monitorer, simplement pour qu’un user soit créé et qu’on lui donne le droit de visualiser les tables et vues de sys, ce que seul sys peut donner :

Et Next encore une fois!

l) Choisissez le tablespace sur lequel votre user sera autorisé à écrire sur la base distante. Evitez de lui donner le droit d’écrire sur les tbs de production, de toute façon, très peut d’informations seront stoquées dans ce schéma, je vous conseille de pointer vers le tbs users standard:

m) Vérifiez que tout est ok avant de cliquer définitivement sur “Register Database Instance” :

n) Si vous voyez apparaitre à la fin de la log écran “The database instance has been registrer and is now beeing monitored” c’est que tout est ok, sinon … cherchez l’erreur

o) Cliquez sur le bouton “Licence Managmnent” pour renseigner votre licence (Permanente ou Trial), sinon Ignite ne vous autorisera pas à visualiser les stats des données récoltées, ce qui est un peu dommage …

Notez que la version Trial est limitée à 30jours, que toutes les fonctionnalités n’apparaissent pas, et que vous serez obligé d’installer une autre version de Iginte si vous obtenez une licence permanente, par souci de lutte contre le piratage, la version capable d’accepter des licences permanentes ne figure pas en téléchargement libre mais un login/password pour la télécharger vous est communiqué dès que vous avez acquis la licence :

p) Renseigner votre clé, et cliquez sur “Add Licence”

4) Utilisation

Utilisez maintenant votre browser préféré et allez à http://<ip_de_votre_machine>:8123, donnez le mot de passe du user ignite de votre repository créé en 3.d) et vous verrez alors appraitre l’interface IGNITE qui vous donnera un apperçu temps reel de la cpu de votre machine Oracle, des IO physiques et logiques, des différentes opérations qui ont été consomatrices heure par heure, …

Vous pouvez consulter la partie “CURRENT” qui est le temps réel pour la partie “TREND” qui est l’archivage, pour regarder à postérieure le comportement de votre database.

Vous verrez que le produit est très complet et qu’il vous permet de retourner dans tous les sens les indicateurs de perfs (les users, les programmes, les temps, les waits, les requetes, …)

A vous de découvrir le produit !

l’idéal est de disposer d’une console unique dans l’entreprise où les différents serveurs vont inscrire leurs diverses informations initialement destinés à des fichiers de log locaux. Une telle console permet de superviser rapidement l’ensemble des messages de l’ensemble des serveurs d’une entreprise.

Un élément essentiel qui peut par exemple se coupler à un superviseur Nagios pour une vue parfaite des resources de l’entreprise.

1) Introduction

11. Généralités

Il existe plusieurs formats de gestion de messages de logs, les plus connus sont SYSLOG (qui se décline en plusieurs normes) et WindowsEvent. Les formats SYSLOG sont généralement utilisés dans les mondes UNIX-like alors que les autres utilisent des formats propriétaires … (no comment).

Nous avons choisi de construire le Serveur de Logs Central (SLC) sous le format syslog dernière génération (norme RSYSLOG) et de convertir les autres formats vers celui-ci (syslog, syslog-ng et WindowsEvent) afin de faire remonter sur cette console tous les logs de l’entreprise sans discrimination.

1.2 Le serveur SYSLOG

Un serveur SysLog est un serveur comme un autre, il a la faculté d’écouter d’éventuels clients qui veulent lu idélivrer des messages de log sous divers formes (sockets UNIX, sockets IP, etc) et, selon la configuration que l’on en fera, stoquera ces messages en fonction de divers critères et sur différents médias (fichiers text, base de données, mails, …).

Nous avons choisi dans notre exemple d’utiliser le protocole syslog pour que celui-ci stoque tous les messages qui lui sont annoncés dans une base de données au format MySQL, permet de greffer éventuellement et facilement une interface web permettant d’administrer facilement ces différents messages?

Exemple de réalisation web pour l’entreprise XXX :

1.3 Bases de construction de cet exemple

Dans cet article, notre SLC est basé sur une distribution Linux openSuSE 11.3 64bits.

Les prérequis sont, parmi les packages standards de cette distribution (rien d’extraordinaire) :

- RSYSLOG

- MYSQL community edition

- php 5.x + module php_mysql

2) Les serveurs au format SYSLOG

2.1 Présentation d’un serveur RSYSLOG (dernière génération)

Le fichier de configuration du serveur RSyslog est généralement /etc/rsyslog.conf.

Prenons par exemple la configuration RSyslog pour un serveur de mails (postfix) :

$ModLoad immark.so
$ModLoad imuxsock.so
$ModLoad imklog.so
$klogConsoleLogLevel 1
$WorkDirectory                  /var/log/rsyslog.work
$ActionQueueType                LinkedList
$ActionQueueFileName            srvrfwd
$ActionResumeRetryCount         -1
$ActionQueueSaveOnShutdown      on

mail.info               /var/log/mail.info
mail.warning            @@logserver:514
mail.err                @@logserver:514

 if      ($programname != 'postfix') \
then    @@logserver:514
&       ~

Dans cet exemple, le serveur “logserver” est le nom DNS de notre serveur central de logs, celui-ci est indiqué dans le fichier /etc/hosts du serveur local.

Ici nous demandons plusieurs choses, l’envoi en UDP (port 514 standard) de tous les messages syslog que reçoit le serveur Rsyslog local de ce serveur, ceci pour tous les messages de la facility “mail” et la criticité “warning” ou “err“. Cela signifie tous les messages de logs envoyés par les programmes qui se signent en “mail” et qui précisent que les messages sont de type warning ou error.

Les message de type “info” sont en revanche très nombreux sur un serveur smtp très solicité,nous ne préférons pas engorger le réseau avec ce type de flux et préférons continuer le stockage de ces informations dans un fichier local au serveur (il n’y a généralement pas d’information intéréssante à glaner dans les messages de type “info” => inutile de les faire remonter inutilement…)

Notons aussi la directive “workdirectory”, elle est très importante et consiste en un répertoire de spool dans lequel stoquer les messages dans le cas où le serveur central serait injoignale pendant un certain temps en afin de ne pas perdre ces messages.

Enfin, en plus de la politique précédente, dans les dernières lignes, notons que nous ne souhaitons pas recevoir sur le SLC les lessages provenant du serveur “postfix” mais que nous souhaitons recevoir tous les autres (messages systèmes, etc).

Généralement nous ne nous attarderons pas à “éliminer” certains messages de logs à envoyer vers le SLC mais de temps en temps, comme dans le cas d’un serveur de mails, d’un DNS, etc, il peut arrive de vouloir exclure une partie des messages dans un but de lisibilité et de performance.

2.2 Communication avec d’autres serveurs de Log

2.2.1 Rsyslog vers Rsyslog

Informations décrites en 2.1, voir descriptif du /etc/rsyslog.conf

2.2.1 syslog vers Rsyslog

Syslogd est la premire version des démons syslog, le fichier de conf est /etc/syslog.conf.

Le principe est le même, on donne des règles de log (fichiers locaux, mails, …) en fonction de falility (signature des programmes “mail”, “cron”, …) et des levels (info, warning, err, …).

Exemple de /etc/syslog.conf:

*.info;mail.none;authpriv.none;cron.none                /var/log/messages

authpriv.*                                              /var/log/secure

mail.*                                                  /var/log/maillog

cron.*                                                  /var/log/cron

*.emerg                                                 *

uucp,news.crit                                          /var/log/spooler

local7.*                                                /var/log/boot.log

Dans cet exemple, nous avons un syslog.conf classique qui ne logg que dans des fichiers locaux en fonction de <facility>.* ou de *.<level> au choix.

local7.*                                                 @@serveur.de.logs:544

Ou 544 est par défaut le port UDP sur lequel le serveur répondant au nom DNS serveur.de.logs devra écouter.

2.2.2 syslog-NG vers Rsyslog

Les serveurs syslog-NG (NextGeneration) trouvent leur configuration dans /etc/syslog-ng/syslog-ng.conf.

On trouve globalement 3 notions utile dans notre cas dans ces fichiers:

- “options” : le réglagage général du démon syslog-ng

- “source” : identification d’une source de message (facility, level, …)

- “destination” : que doit on faire de ces messages (écriture fichier local, renvoi vers un autre démon syslog, etc)

Exemple:

options {

        use_dns(yes);          <-- utilise les résolutions DNS (recommandé)

        dns_cache(yes);        <-- utilise un cache client DNS (très recommandé)

        use_fqdn(yes);         <-- utilise des full qualified domain name au lieu de noms courts

        keep_hostname(yes);    <-- hostname rewriting ?

        check_hostname(no);

        chain_hostnames(off);

        sync(0);               <-- nombre de lignes à buffersier avant de traiter un flux: 0

                                   recommandé hautement si cvous ne souhaitez pas perdre de message

        stats(43200);

};

source s_everything {          <-- description d'une source potentielle de message et attribution
                                   d'un nom "s_everything"
        internal();

        unix-stream("/dev/log");   <-- tout se qui écrit sur le périphérique /dev/log (ie: tout)

        udp();                     <-- on veut receptionner de l'UDP uniquement

};

destination d_logserver   {  tcp("logserver" port(514)); }; <-- destination "d_logserver"

log {  source(s_everything);  destination(d_logserver); };  <-- on log en fonction de la source
                                                            s_everything et de d_logserver

destination d_fichier { file("/var/log/messages.log"); };    <-- destination "d_fichier"

log { source(s_everything); destination(fichier); };         <-- on log en fonction de la source
                                                             s_everything et de d_fichier

Vous le voyez, vraiment rien de sorcier !

2.2.4 WindowsEvent vers Rsyslog

2.2.4.1 – Introduction

Bon, c’est évidement là que cela commence à pêcher… Car évidement, histoire de ne pas faire dans les standards établis, Microsoft a décidé d’employer un autre protocole de communication pour les messages de log exploités notemmenent dans le monde Windows par l’EventManager que tout le monde ne connait que trop bien.

Le messages ont des niveaux de criticité, des facility, sont présents dans des types de journaux, … un peu comme dans SysLog mais ne sont pas au format SysLog…

Il existe cependant dans le monde du libre et de l’OpenSource des tas de petits softs qui se chargent de traduire un format de message Windows en un format SYSLOG dans le but de l’envoyer vers un serveur SYSLOG, et cela fonctionne très bien!

Nous avons jeté notre dévolu sur l’agent SNARE développé par la société INTERSECTALLIANCE et qui est télévhargeable ici dans une version libre : http://sourceforge.net/projects/snare/

l’Agent SNARE pour Windows fait le café en matière de traduction de message Windows vers du SYSLOG, mais IntersectAlliance propose aussi une version commerciale si vous souhaitez avoir le sucre et le nuage de lait … A mon sens vraiment pas nécéssaire.

Par exemple, SNARE dans sa version gratuite ne sait pas écouter sur les ports TCP mais uniquement sur les ports UDP ce qui est loin d’être un drâme car toutes les versions des différents serveurs SYSLOG parlent l’UDP et que il n’est pas forcément recommandé de faire de l’UDP sur un serveur SYSLOG centralisé afin de ne pas se faire engorger en cas d’afflux massif de messages et de provoquer un deni de service…

2.2.4.1 – Installation de l’Agent SNARE

Là aussi c’est d’une difficulté déconcertante, du moment que vous disposez d’un index normalement constitué pour cliquer sur “Next”, tout se passera bien!

La configuration du logiciel agent SNARE sur votre serveur windows est par contre à peine plus complexe.

2.2.4.2 – Configuration de l’Agent SNARE

Une fois l’agent installé, vous disposez en local d’un petit serveur web qui vous permet de configurer l’agent, de déterminer l’emplacement du serveur SYSLOG Central, de déterminer les mappings Event Windows / Message Syslog que vous souhaitez ainsi exporter vers ce serveur, l’ensemble est sommes toute très bien fait.

Utilisez votre navigateur http préféré depuis votre serveur Windows et connectez vous sur http://localhost:6161 vous verrez alors apparaitre l’écran suivant :

Plusieurs options s’offrent à vous dans le menu de gauche :

A) NETWORK CONFIGURATION:

Ce menu vous permet de renseigner la localisation du serveur syslog central qui va recevoir les message traduits de l’EventViewer de Vindows.

Les principaux champs à renseigner sont :

Override detected DNS Name with :    NOM_MACHINE     <-- le 'hostname' syslog de votre machine
Destination Snare Server address:    logs.domaine.fr <-- le nom dns (ou ip) du serveur syslog central
Destination Port:               :    514             <-- port UDP standard
Enable SYSLOG Header?           :    CHECKED         <-- sinon cela ne sera pas un message syslog
SYSLOG Facility                 :    local7          <-- une facility à associer aux messages Win64
SYSLOG Priority                 :    DYNAMIC         <-- choisissez cette option absolument

Rem: Si “SYSLOG Priority” ne vaut pas “DYNAMIC”, alors tous vos messages auront tous la même priorité (bof)

Rem: “Syslog Facility” est la facility avec laquelle ce message va s’annoncer, vous pourrez en fonction de cette information traiter les messages d’une certaine façon et les différencier des autres. Généralement local7 n’est pas ou très peu utilisé.

Cliquez sur “CHANGE CONFIGURATION” pour que les paramètres soient enregistrés (mais pas encore pris en compte)

B) REMOTE CONTROL CONFIGURATION

Simplement pour restreindre l’utilisation de cette interface web au localhost, ie aux personnes habilitées à ouvrir une session RDP sur le serveur (Administrateurs généralement) :

Cochez simplement la case “Restrict remote control of SNARE agent to certain hosts” et indiquez “127.0.0.1″ (ou “localhost”) dans le champ “IP Address allowed to remote control SNARE”, l’interface est vérouillée.

C) OBJECTIVES CONFIGURATION

C’est cette partie qui va vous permette de définir le mapping entre un message Windows et un message au format SysLog.

Par défaut, vous verrez un certain nombre de message déjà configurés, symbolisés par une ligne dans un tableau html. Généralement ces messages ne conviennent pas et sont uniquement donnés à titre d’exemples, je vous conseille de les supprimer en cliquant autant de fois que nénessaire sur le bouton “DELETE” pour chaque ligne.

Une fois les lignes d’exemples supprimées, vous allez pouvoir ajouter vos propres lignes de mapping de message, c’est à dire de traduction de messages windows spécifiques en messages de type syslog et à envoyer vers votre serveur syslog central.

Cliquez sur “ADD“, la fenêtre suivante apparaît alors :

Voici la signification des difrérents champs “utiles” et les “best pratice” à appliquer :

Identify the high level event: Indique le type d'évènement Windows concerné (les logons/logoff, les arret/marche de services, ...), il convient, dans la pluspart des cas de choisir "ANY EVENT(S)"

Select the Event ID Match Type: Une notion d'inclusion / exclusion. Sauf dans certains cas complexes imposés par votre production, vous préfererez "INCLUDE"

Event ID Search Term: Des mots clés pour filtrer les messages Windows à intercepter. Nous allons dans la pluspart des cas choisir "*" ce qui signifie "tout les messages", mais vous pourriez être amenné, en fonction de vos applicatifs, à utiliser des wildcards plus complexes ("*toto*" <-- bon ok, c'est pas très complexe... mais ça fonctionnerait)

General Search Term: *

User Search Term: *

Identify the event types to be captured: Les "Success Audit" et "Failure Audit" ne présentent pas grand intérêt pour notre utilisation, par contre "INFORMATION", "WARNING" et "ERROR" nous intéressent plus particulièrement dans le cadre des messages SYSLOG. Selon la valeur indiquée dans le paramètre suivant (Select the Alert Level) nous cocherons l'une ou l'autre de ces options. L'idée est: quelle est la notion de criticité que nous souhaitons paralléliser avec la notion de criticité d'un message syslog.

Identify the event logs: Les journaux Windows concernés. Si nous sommes intéressé par tous les message de type "ERREUR", pourquoi se limiter à un journal ? Nous allons donc cocher tous les journaux. Seul un cas particulier exigé par votre production pourra vous amener à effectuer un choix différent.

Select the Alert Level: paramètre FONDAMENTAL. Il s'agit, en fonction de tout ce que nous avons catégorisé précédemment, et notamment avec l'option "Identify the event types to be captured" de faire un parallèle avec un niveau de criticité SYSLOG. Essayez de faire un parallèle correct entre les deux notions pour ne pas avoir de niveaux de criticité incohérents par rapport à l’importance du message Windows...

Une fois ces options indiquez, vous pourrez cliquer sur “CHANGE CONFIGURATION” pour la voir apparaître dans la liste des mappings de messages comme indiqué dans le début de ce chapitre (ouf enfin!)

C) APPLY THE LATEST CONFIGURATION

Une fois tout ceci fait, une fois toutes vos règles de mapping définies, celles-ci ne sont pour autant pas encore prise en compte par le démon SNARE, il faut pour cela se rendre dans la section “Apply the latest configuration” et cliquer sur “RELOAD SETTINGS“.

A partir de cet instant, vos mappings sont actifs et, normalement, SNARE doit envoyer toutes ces traductions de messages Windows vers votre serveur de logs SYSLOG central, vous pouvez vérifier cela en cliquant sur “LATEST EVENTS” dans le menu de gauche de l’interface web SNARE, vous verre zalors un écran du style :

Ce qui signifie alors que (probablement) tout va bien! Il ne vous reste plus qu’a constater la conne reception de ces messages dans cotre SLC.

3) Configuration du serveur SYSLOG central

Dernière brique à notre édifice, la construction du serveur SLC. Celle-ci ne s’écarte pas vraiment d’une configuration standard hormis le fait que nous allons la configurer pour que tous les messages reçus soient inscrits dans une base de données MySQL dont nous allons créer dans un premier lieur la structure.

3.1) Création de la base de données

Nous avons choisi ici le choix de MySQL car c’est le pokus simple à mettre en oeuvre et les structures de tables MyISAM s’appliquent tout à fait à ce genre de typologie en matière de stockage de données (très peu de requêtes croisées, très peu de jointures, beaucoup de balayage de tables simples).

Et puis en plus, pour le moment, dans sa version community, celle-ci est totalement gratuite et full founctionality. Ceci aurait été impossible à faire avec de l’Oracle par exemple sans que cela nous coûte très cher (même dans la version XE, la database ne doit pas exéder 4Gb, hors, dans notre cas, l’entreprise XXX qui utilise cette méthode depuis 1 mois pour son DataCenter possède déjà des tables de plus de 20Gb…)

CREATE DATABASE `syslog`;

CREATE TABLE `client` (
  `client` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `libelle` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `login` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `password` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `ackSequence` text COLLATE utf8_unicode_ci,
  `allServersAccess` tinyint(4) DEFAULT '-1',
  `alerteSonore` tinyint(4) DEFAULT '-1',
  PRIMARY KEY (`client`)
) ENGINE=MyISAM AUTO_INCREMENT=11 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

CREATE TABLE `clientHost` (
  `clientHost` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `client` INT(11) DEFAULT NULL,
  `ipaddr` VARCHAR(20) COLLATE utf8_unicode_ci DEFAULT NULL,
  `libelle` VARCHAR(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `abreviation` VARCHAR(20) COLLATE utf8_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`clientHost`),
  KEY `IDX1` (`ipaddr`)
) ENGINE=MYISAM AUTO_INCREMENT=76 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
CREATE INDEX `idxx_clientHost_ipaddr ON clientHost(ipAddr);

CREATE TABLE `clientLogsAck` (
  `clientLogsAck` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
  `client` BIGINT(20) DEFAULT '-1',
  `seq` BIGINT(20) DEFAULT '-1',
  `dateAck` DATE DEFAULT NULL,
  `timeAck` TIME DEFAULT NULL,
  PRIMARY KEY (`clientLogsAck`)
) ENGINE=MYISAM AUTO_INCREMENT=53016 DEFAULT CHARSET=latin1

CREATE TABLE `logsMasking` (
  `logsMasking` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
  `client` BIGINT(20) DEFAULT NULL,
  `wildcard` VARCHAR(255) DEFAULT NULL,
  `information` VARBINARY(255) DEFAULT NULL,
  `datecreation` DATETIME DEFAULT NULL,
  `ipaddr` VARCHAR(255) DEFAULT NULL,
  `actif` TINYINT(1) DEFAULT NULL,
  PRIMARY KEY (`logsMasking`)
) ENGINE=MYISAM AUTO_INCREMENT=71 DEFAULT CHARSET=latin1

CREATE TABLE `logs` (
  `seq` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
  `ipaddr` VARCHAR(20) COLLATE latin1_general_ci DEFAULT NULL,
  `host` VARCHAR(32) COLLATE latin1_general_ci DEFAULT NULL,
  `facility` VARCHAR(10) COLLATE latin1_general_ci DEFAULT NULL,
  `priority` VARCHAR(10) COLLATE latin1_general_ci DEFAULT NULL,
  `level` VARCHAR(10) COLLATE latin1_general_ci DEFAULT NULL,
  `tag` VARCHAR(10) COLLATE latin1_general_ci DEFAULT NULL,
  `date` DATE DEFAULT NULL,
  `time` TIME DEFAULT NULL,
  `program` VARCHAR(15) COLLATE latin1_general_ci DEFAULT NULL,
  `msg` TEXT COLLATE latin1_general_ci,
  `ack` TINYINT(4) DEFAULT '-1',
  PRIMARY KEY (`seq`),
  KEY `host` (`host`),
  KEY `program` (`program`),
  KEY `time` (`time`),
  KEY `date` (`date`),
  KEY `priority` (`priority`),
  KEY `facility` (`facility`),
  KEY `IDX2` (`ipaddr`)
) ENGINE=MYISAM AUTO_INCREMENT=89272745 DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci

CREATE INDEX `idx_logs_host ON `logs`(host);
CREATE INDEX `idx_logs_program ON `logs`(program);
CREATE INDEX `idx_logs_time ON `logs`(time);
CREATE INDEX `idx_logs_date ON `logs`(date);
CREATE INDEX `idx_logs_priotity ON `logs`(priotity);
CREATE INDEX `idx_logs_facility ON `logs`(facility);
CREATE INDEX `idx_logs_ipaddr ON `logs`(ipaddr);

CREATE DATABASE `syslog_arch;

CREATE TABLE `logsArchives` (
  `logsArchives` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
  `ipaddr` VARCHAR(20) COLLATE utf8_unicode_ci DEFAULT NULL,
  `host` VARCHAR(32) COLLATE utf8_unicode_ci DEFAULT NULL,
  `facility` VARCHAR(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  `priority` VARCHAR(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  `level` VARCHAR(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  `tag` VARCHAR(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  `date` DATE DEFAULT NULL,
  `time` TIME DEFAULT NULL,
  `program` VARCHAR(15) COLLATE utf8_unicode_ci DEFAULT NULL,
  `msg` TEXT COLLATE utf8_unicode_ci,
  `ack` TINYINT(4) DEFAULT NULL,
  PRIMARY KEY (`logsArchives`),
  KEY `host` (`host`),
  KEY `program` (`program`),
  KEY `time` (`time`),
  KEY `priority` (`priority`),
  KEY `facility` (`facility`),
  KEY `IDX2` (`ipaddr`)
) ENGINE=MYISAM AUTO_INCREMENT=3554442 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

CREATE INDEX `idx_logsArchives_host ON `logs`(host);
CREATE INDEX `idx_logsArchives_program ON `logs`(program);
CREATE INDEX `idx_logsArchives_time ON `logs`(time);
CREATE INDEX `idx_logsArchives_date ON `logs`(date);
CREATE INDEX `idx_logsArchives_priotity ON `logs`(priotity);
CREATE INDEX `idx_logsArchives_facility ON `logs`(facility);
CREATE INDEX `idx_logsArchives_ipaddr ON `logs`(ipaddr);

$Modload ommysql 
$ModLoad immark
$ModLoad imuxsock
$ModLoad imklog
$ModLoad imudp.so
$ModLoad imtcp.so
*.info;mail.none;authpriv.none;cron.none                -/var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog
cron.*                                                  -/var/log/cron
*.emerg                                                 *
uucp,news.crit                                          -/var/log/spooler
local7.*                                                /var/log/boot.log
$template syslog,"insert into logs(ipaddr, host, facility, priority, level, tag, date, time, program, msg) values ('%fromhost-ip%', '%HOSTNAME%', '%syslogfacility-text%', '%syslogpriority-text%', '%syslogseverity-text%', '%syslogtag%', '%timereported:::date-mysql%', '%timereported:::date-mysql%', '%programname%', '%msg%')", SQL
*.* >127.0.0.1,syslog,syslogLogin,syslogPassword;syslogTpl
$UDPServerRun 514
$UDPServerAddress 192.168.12.5
$InputTCPServerRun 514

/dev/mapper/mpath5p1   99G  188M   94G   1% /DATA/index
/dev/mapper/mpath6p1   99G  7,6G   86G   9% /DATA/data
/dev/mapper/mpath8p1   50G  8,2G   39G  18% /DATA/arch     <== partition a redimensionner
/dev/mapper/mpath9p1   50G  533M   47G   2% /DATA/ctltemp
/dev/mapper/mpath12p1

parted /dev/mapper/mpath8
(parted) print
    Number  Start   End    Size   Type      File system  Fanions
    1      32,3kB  215GB  215GB  primaire  ext3
(parted) rm 1            <== en cet instant il n'y a plus de donnees exploitables !
                             Soit vous allez au bout de la procédure, soit c'est la démission  ...
(parted) mkpart
    Type de partition?  primary/primaire/extended/étendue? primary
    Type de système de fichiers?  [ext2]? ext3
    Début? 32,3kB
    Fin? 120G
(parted) print
    Number  Start   End    Size   Type      File system  Fanions
    1      32,3kB  120GB  120GB  primaire  ext3       <== verifier la prise en compte, c'est gagné...

Remarque: Vous ne devez surtout pas utiliser fdisk (ou un autre utilitaire de manipulation des partitions de volumes simples) car celui-ci va détruire la configuration multipah associé à une LUN et risque de vous faire perdre la totalité de vos données.

e2fsck -f /dev/mapper/mpath8p1
resize2fs 1.39 (29-May-2006)
Resizing the filesystem on /dev/mapper/mpath8p1 to 29296527 (4k) blocks.
Le système de fichiers /dev/mapper/mpath8p1 a maintenant une taille de 29296527 blocs.

/dev/mapper/mpath5p1   99G  188M   94G   1% /DATA/index
/dev/mapper/mpath6p1   99G  7,6G   86G   9% /DATA/data
/dev/mapper/mpath8p1   200G  8,2G   39G  8% /DATA/arch <== ok !! On ne démissionne pas aujourd'hui!
/dev/mapper/mpath9p1   50G  533M   47G   2% /DATA/ctltemp
/dev/mapper/mpath12p1

1.1       Le cluster MySQL : DRBD + HEARTBEAT + Master/Slave MySQL

1.1.1      Pourquoi un cluster HA au lieu d’un cluster NDB ?

MySQL propose dans sa suite logicielle, un moteur de Cluster (NDB). Cette solution de continuité de service est très restrictive en matière applicative et ne s’adapte pas à nos besoins (requêtes à jointures complexes non clusterisables).

Nous avons choisi une deuxième méthode de clusterisation, une solution de Haute Disponibilité (Hight Avaliability ou HA) basée sur plusieurs briques applicatives.

1.1.2      Les différentes briques du cluster MySQL HA

1.1.2.1         Réplication des données avec « DRBD »

DRBD (Data Replication Block Device) est un programme qui permet de faire de la réplication de données au sens « block » d’unité de stockage (disque, …)

DRBD s’interpose entre l’OS et le périphérique de stockage (dans notre exemple, une partition sur un disque en RAID1) : à chaque fois que l’OS ordonne l’écriture d’un block au contrôleur, c’est sur un périphérique virtuel (/dev/drbd) et une partition virtuelle (/dev/drbd0) que l’OS s’adresse.

DRBD va alors contacter son homologue pour la réplication de ce block (secondary server) et, celui-ci, va écrire le block sur sa propre partition, puis (optionnellement) envoyer une information d’écriture complétée (commit) au serveur maitre (primary server).

Les blocks répliqués peuvent se faire de façon synchrone ou asynchrone en fonction des configurations matérielles et du positionnement  des différents nœuds composant un cluster DRBD.

Remarque : Dans le cadre d’un cluster DRBD, la partition virtuelle (/dev/drbd0) du serveur secondaire n’est pas montée et n’est pas accessible par l’OS. En effet, il ne faut pas que l’OS du serveur secondaire écrive des blocks qui n’appartiendraient pas au serveur primaire : le cluster serait alors corrompu.

Remarque : La réplication au sens de DRBD se fait au niveau block-device et non au niveau logique (fileSystem). Si un block de données est corrompu, il sera répliqué et le serveur secondaire aura lui aussi le même block corrompu. Si cette corruption est fatale (partition illisible, filesystem irréparable, …) => Le cluster DRBD est définitivement perdu (le primaire et le secondaire).

1.1.2.2         Bascule d’un nœud mort vers un nœud vivant avec « HeartBeat »

Les deux nœuds du serveur DRBD sont en mode ACTIF / PASSIF. C’est-à-dire que, en cas de crash du primary server (le nœud actif), il faut aller démarrer l’ensemble des services sur le secondary server car ceux-ci sont arrêtés pour que la réplication puisse se faire correctement.

Pour automatiser la détection du nœud mort et d’automatiser la bascule et le démarrage automatique des services sur le nœud secondaire, nous allons utiliser le programme HeartBeat qui fera tout cela pour nous.

1.1.2.3         Réplication MySQL native « Master / Slave »

Afin de se prémunir de la corruption de blocks dans le cadre d’un cluster DRBD (voir 1.1.2.1) , même si ce cas de figure est très rare, nous allons mettre en place une réplication logique des données de notre cluster MySQL afin de pouvoir récupérer une version des données « au plus près » d’un crash et dans le cas de corruption du cluster DRBD.

1.2       Le cluster « exemple » :

Dans ce document, nous allons nous baser sur la configuration du cluster “XXX” (Cluster MySQL pour le client “XXX” de l’entreprise).

Ce cluster est composé de deux machines physiques pour le cluster MySQL / DRBD et d’une VM (pool Xen XXX-POOL) pour l’esclave MySQL issu de la réplication MASTER/SLAVE.

Le « réseau DRBD » est destiné à la réplication au sens de DRBD, il est composé de deux interfaces GBits reliées par un cable croisé.

L’ensemble des données à répliquer au sens de DRBD sera monté dans un point de montage « /data » qui contiendra pour MySQL : les configurations, les datas, les sauvegardes, …

Remarque : Les trois machines ont un point commun : elles disposent toutes d’un serveur MySQL, nous utiliserons une normalisation du filesystem qui sera commune à toutes les machines du cluster pour une meilleure lisibilité.

2.  Installations et Configurations

2.1       Normalisation des filesystems

Sur les trois nœuds du cluster MySQL, nous allons utiliser le nommage suivant :

Remarque : N’oublions pas que sur le secondary-DRBD le point de montage « /data » est vide car la partition n’est pas montée, seul le processus de réplication DRBD du serveur y a accès pour écrire les blocks provenant du primary-DRBD.

2.2       Installation du cluster DRBD

2.2.1      Les packages

Cette installation est basée sur une openSuSE 11.3 64bits. Les packages DRBD sont présents dans la distrib et installable par YAST:

-          drbd-8.3.7-2.5.x86_64

-          yast2-drbd-2.13.1-221.2.noarch               (managment par Yast : optionnel)

2.2.2      Configuration

2.2.2.1         Fichier de configuration principal

Un seul fichier de configuration est nécessaire eu bon fonctionnement de DRBD, attention, ce fichier doit être identique que le primary et le secondary.

a.       Détails du fichier /etc/drbd.conf :

global {   usage-count yes;    }

common {

protocol C;

handlers {

pri-on-incon-degr     “/usr/lib/drbd/notify-pri-on-incon-degr.sh;

/usr/lib/drbd/notify-emergency-reboot.sh;

echo b > /proc/sysrq-trigger ;

reboot -f”;

pri-lost-after-sb     “/usr/lib/drbd/notify-pri-lost-after-sb.sh;

/usr/lib/drbd/notify-emergency-reboot.sh;

echo b > /proc/sysrq-trigger ;

reboot -f”;

local-io-error         “/usr/lib/drbd/notify-io-error.sh;

/usr/lib/drbd/notify-emergency-shutdown.sh;

echo o > /proc/sysrq-trigger ;

halt -f”;

}

startup {    }

disk {

on-io-error detach; ó Sur une I/O error, on arrête de répliquer !

}

net {

cram-hmac-alg “sha1″;

shared-secret “drbd-sql”;       ó clé de hashage pour la communication

entre les noeuds

}

syncer {

rate 800M;                 ó Taux de transfert voulu sur le lien de réplication

al-extents 257;

}

}

resource cluster0{                                ó NOM DE NOTRE CLUSTER DRBD

protocol C;    TYPE DE REPLICATION : C ó synchrone

A ó Asynchrone

B ó semi synchrone (en mémoire)

net {

cram-hmac-alg “sha1″;

shared-secret “drbd-sql”; ó mot de passe sha1

}

on sql-primaire {          ó nom DNS du primary DRBD

device /dev/drbd0;   ó nom de la partition virtuelle

disk /dev/sda4;                   ó nom de la partition réelle

address 192.168.168.1:8888; ó IP et port TCP de réplication DRBD

meta-disk internal;

}

on sql-secondaire {              ó Pareil sur le secondaire

device /dev/drbd0;

disk /dev/sda4;

address 192.168.168.2:8888;

meta-disk internal;

}

}

b.       Importance du fichiers /etc/hosts

Afin de se prémunir des problématiques DNS, il convient d’indiquer dans le fichier hosts de chaque nœud DRBD les adresses et noms de leurs homologues.

-          Sur le PRIMARY comme sur le SECONDARY

…

192.168.13.98   sql-primaire

192.168.13.99   sql-secondaire

…

2.2.2.2         La  préparation de la partition virtuelle DRBD

Les deux serveurs DRBD sont dans notre cas configurés pour utiliser un disque logique « /dev/sda » en RAID-1 sur deux disques physiques.

Sur les deux serveurs, il va falloir créer une partition (« /dev/sda1 ») de même taille et de même nom.

Dans notre cas, nous allons utiliser une partition de 100Go sur le disque.

Attention cette partition ne doit pas être formatée car DRBD doit y inscrire des données qui lui sont propres (« méta données ») et qui servent à la réplication entre le primary et le secondary. Le formatage s’éffectuera sur la partition virtuelle de DRBD (voir ) qui saura préserver ainsi ses méta datas.

Méthode à appliquer sur le PRIMARY (uniquement) :

1)       fdisk /dev/sda                                                                       on crée la partion de 100Go /dev/sda1

2)      drbdadm create-md all                                                       création des metadatas dans la partinion

3)      rcdrbd start                                                                              démarrage du démon drbd

4)      drbdadm — –overwrite-data-of-peer primary all    ceci est le nœud primaire DRBD

5)      mkfs.ext3 /dev/drbd0                                                         formatage en préservant les métadonnées

Remarque :

Si des informations apparaissent sur les premiers blocks de la partition et indiquant que celle-ci a déjà été formatée auparavant, DRBD va refuser d’y créer les métadonnées, même si la partition a été détruite et re-créée. Il faut détruire les blocks avec :

-          dd if=/dev/zero bs=1M count=1 of=/dev/sda4

-          sync

Puis poursuivre au point 2).

Méthode à appliquer sur le SECONDARY (uniquement) :

Même chose que pour le PRIMARY à l’exception du formattage ext3. Nous allons également renseigner ce nœud qu’il est le secondaire.

1)      fdisk /dev/sda                                                                               on crée la partion de 100Go /dev/sda1

2)      drbdadm create-md all                                                                              création des metadatas dans la partition

3)      rcdrbd start                                                                                     démarrage du démon drbd

4)      drbdadm secondary all                                                                               ceci est le nœud secondaire DRBD

Remarque : Il faut attendre un certain temps avant que la totalité de la partition drbd soit répliquée sur le nœud secondaire, on peut voir l’évolution avec  (dans cette exemple depuis le PRIMARY NODE):

> cat /proc/drbd

version: 8.3.7 (api:88/proto:86-92)

srcversion: 04F43AA72D62F7D4F0CB048

0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r—-

ns:13985900 nr:0 dw:1947208 dr:12043684 al:930 bm:752 lo:1 pe:115

ua:142 ap:0 ep:1 wo:b oos:101513508

[=>..................] sync’ed: 12.1% (99132/112756)M

finish: 0:13:22 speed: 126,520 (108,976) K/sec

Lorsque la synchronisation sera achevée la commande donnera un message ressemblant à :

> cat /proc/drbd

version: 8.3.7 (api:88/proto:86-92)

srcversion: 04F43AA72D62F7D4F0CB048

0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r—-

ns:115495756 nr:0 dw:1947208 dr:113549000 al:930 bm:7048 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

2.2.3      Arrêt / Marche du Cluster DRBD

Le script d’init /etc/init.d/drbd (ou rcdrbd) accepte les commutateurs « stop » ou « start ». Ceci a pour effet de démarrer le processus DRBD, sur le primary comme sur le secondary, mais les datas ne sont pas encore disponible à ce stade, il faudra monter la partition sur le point de montage voulu, à savoir :

Sur chacun des serveurs, le processus de réplication écoute, comme indiqué dans le fichier de configuration global, sur le port TCP 8888.

2.2.3.1         Démararge du CLUSTER DRBD :

Deux opérations sont à éffectuer :

-          Sur le PRIMARY  (en premier):

rcdrbd start

mount /dev/drdb0   /data

-          Sur le SECONDARY :

rcdrbd  start

(pas de montage de /data évidement…)

Arrêt du cluster DRDB :

-          Sur le PRIMARY  (en premier)

rcdrbd stop

umount /data

-          Sur le SECONDARY

rcdrbd stop

2.2.4      Supervision du cluster DRBD

L’état de la réplication DRBD, sur le primaire comme sur le secondaire, s’éffectue en capturant le contenu de « /proc/drbd »

Sur le primary :

> cat /proc/drbd

> version: 8.3.7 (api:88/proto:86-92)

> srcversion: 04F43AA72D62F7D4F0CB048

> 0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r—-

>    ns:72 nr:0 dw:1164292 dr:115974011 al:218 bm:7071 lo:0 pe:0 ua:0 >ap:0 ep:1 wo:b oos:0

Sur le secondary :

> cat /proc/drbd

> version: 8.3.7 (api:88/proto:86-92)

> srcversion: 04F43AA72D62F7D4F0CB048

> 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r—-

>    ns:72 nr:0 dw:1164292 dr:115974011 al:218 bm:7071 lo:0 pe:0 ua:0 >ap:0 ep:1 wo:b oos:0

Avec :

RO=Primary/X sur le primaire, Secondary/X sur le secondaire

avec X={ Primary | Secondary | DUnknown <= problème ! }

CS=état de la connexion réseau de réplication

NS=bytes émis

NR=bytes reçus

DW=données écrites physiquement sur le disque

DR=Données lues sur le disque

2.3       Installation de la réplication MySQL Maitre / Esclave

2.3.1      Configuration du maitre

Activer la journalisation des logs binaires dans /etc/my.cnf :

log-bin

Créer un user pour la réplication et qui sera utilisé par le SLAVE, puis lui donner les droits d’accèder au processus de réplication :

mysql> create user replic identified by replic ;

mysql> GRANT REPLICATION SLAVE ON *.* TO ‘replic’@'%’ IDENTIFIED BY ‘replic’;

mysql> GRANT SELECT, PROCESS, FILE, SUPER, RELOAD ON *.* TO ‘replic’@'%’ IDENTIFIED BY ‘replic’;

Modifier le fichier de conf global du maitre (/etc/my.cnf)  pour lui indiquer les bases qu’il ne doit pas répliquer :

…

binlog-ignore-db = mysql

binlog-ignore-db = base_a_exclure

…

2.3.2      Configuration de l’esclave

2.3.2.1         Modification du fichier de conf global

Modifier le fichier /etc/my.cnf du SLAVE et ajouter :

server-id           = 10  ó identifiant différent de celui du maitre

relay-log           =/data/mysql/logs/binary/relaybinlog.rotation

relay-log-index     =/data/mysql/logs/binary/relaybinlog.index

relay-log-info-file =/data/mysql/conf/relay-log.info

master-info-file    =/data/mysql/conf/master.info

Redémarrer MySQL pour le prendre en compte (« rcmysql restart »)

2.3.2.2         Initiation du processus de réplication

a)      Arreter (éventuellement) le processus ESCLAVE :

Mysql> stop slave ;

b)      Faire un dump SUR LE MAITRE des bases à restaurer SUR L’ESCLAVE pour initier le processus :

Maitre> mysqldump           -h localhost

-uroot

–lock-all-tables

–master-data óContient les SCN des binarylogs pour l’esclave

–databases mabase

–flush-logs

–add-drop-database –allow-keywords

–quick

–complete-insert

–add-drop-table

–create-options

–dump-date

–triggers –routines –events

–debug-info

–verbose

–comments

–result-file=mondump.sql

c) restaurer le dump précédent sur l’esclave

esclave> mysql –uroot –D mabase < mondump.sql

d)      Repérer dans le dump précédent le nom du fichier de log binaire renseigné par le Maitre lors du dump ainsi que la position dans ce log.

(imaginons que le nom du log soit « ’binarylog.000062 », que la position dans le log soit « 106 » et que l’addresse IP source physique du maitre soit ’192.168.13.98′)

Il faut ensuite informer l’esclave de ces données en tapant :

mysql> change master to

master_host=    ’192.168.13.98′,

master_user=    ‘replic’,

master_password=’replic’,

master_log_file=’binarylog.000062′,

master_log_pos= 106;

Il faut ensuite démarrer le processus de récplication sur l’esclave :

mysql> start slave ;

mysql> show slave status\G ;

2.4       Installation de HeartBeat

2.4.1      Présentation

HeartBeat est basé sur une interrogation régulière de ses voisins afin de déterminer si, oui ou non, un nœud d’un cluster est mort ou non (/etc/ha.d/ha.cf)

S le cas où HeartBeat constate, depuis un nœud « passif », qu’un nœud dit « actif » est mort, alors un ensemble de processus est déclanché pour prendre l’identité de l’ancien nœud actif maintenant mort (/etc/ha.d/haresources).

L’ensemble des programmes et scripts dont HeartBeat va se servir sont dans /etc/ha.d/resource.d/.

2.4.2      Configuration de /etc/ha.d/ha.cf

Ce fichier contient la config générale de HeartBeat, il doit être présent à l’identique sur le nœud ACTIF et sur le nœud PASSIF.

logfile /var/log/ha.log              fichier de log standard

debugfile /var/log/ha-debug.log      fichier de log supplémentaire (debug)

logfacility     local0               facility de syslogd

keepalive 2                          On teste toutes les 2 secondes l’état des nœuds.

warntime 8                           On alerte si un nœud ne répond pas durant 8 secondes.

deadtime 15                          A 15 secondes, on considère que le nœud est mort.

initdead 30                          Temps de démarrage max toléré avant de diagnostiquer que le nœud est mort.

mcast bond0 225.0.0.1 694 1 0        cartes réseaux (mcast ou bcast) pour atteindre les HeartBeats

mcast eth2  225.0.0.1 694 1 0        cartes réseaux (mcast ou bcast) pour atteindre les HeartBeats

auto_failback off                    Pas de retour arrière automatique, trop dangereux

node sql-primaire                 quels sont les nœuds composant la ferme HeartBeat ?

node sql-secondaire               quels sont les nœuds composant la ferme HeartBeat ?

ping 192.168.13.253                  Chaque nœud doit également pouvoir accèder à la gateway

pour être caractérisé de « vivant ».

deadping 5                           si le ping ne répond pas pendant 5 secondes, la cible est considérée comme morte.

respawn hacluster /usr/lib64/heartbeat/ipfail

apiauth ipfail gid=haclient uid=hacluster

2.4.3      Configuration des resources HA

Dans le cas où un nœud passif HeartBeat considère que son pendant actif est mort, il va déclancher un certain nombre d’actions pour prendre son identité. Ces actions sont décrites dans le fichier /etc/ha.d/ haresources.

Les ordres commencent par spécifier le hostname du serveur actif à monitorer (le primaire) puis une série d’actions séparées par des espaces.

Si une (ou plusieurs) adresse IP figurent comme action dans une liste d’action, cela signifie que HeartBeat doit dynamiquement assigner à une de ses cartes réseaux cette adresse IP (principe d’adresse IP virtuelle). Ce procédé permet de s’affranchir d’un LoadBalancer.

Exemple sur le custer SQL :

…

otsql-primaire   192.168.13.100    drbddisk::cluster0    Filesystem::/dev/drbd0::/data::ext3    mysql

…

Découpage :

hostname du primaire actif : otsql-primaire       (ne pas oublier de renseigner les fichiers hosts)

Action 1 : drbddisk::cluster0

Action 2 : Filesystem::/dev/drbd0::/data::ext3

Action 3 : 192.168.13.100

Action 4 : mysql

Explications :

Action1 : va déclencher le programme /etc/ha.d/resources.d/drbddisk avec le paramètre cluster0. Ce programme a pour effet de positionner dynamiquement le nœud DRBD comme PRIMARY  (voir 2.2.2.2)

Action2 : déclenche le programme /etc/ha.d/resources.d/Filesystem en lui passant trois paramètres « /dev/drbd0 », « /data » et « ext3 ». Ce programme va dynamiquement monter la partition virtuelle DRBD sur la partition physique qui lui est associée sur le point de montage /data.

Action3 : assigne l’adresse IP 192.168.13.100 à une de ses interfaces présente sur ce réseau

Action4 : déclenche le programme /etc/ha.d/resources.d/mysql qui démarre le serveur MySQL sur le nœud nouvellement actif.

2.5       Bascule du cluster : FAIL-OVER / FAIL-BACK

Le Cluster HA DRBD/MySQL doit basculer sur le nœud SECONDAIRE en cas d’indisponibilité du nœud PRIMARY jugé par HeartBeat. Cette indisponibilité est caractérisée par l’impossibilité des deux HeartBeat de se voir mutuellement et d’un certain nombre de critères (Je ne vois pas le HeartBeat en face mais vois-je la passerelle ? etc).

2.5.1      FAIL OVER :

Dans le cas « théorique » où l’on voudrait basculer du nœud primaire vers le nœud secondaire du cluster DRBD (dans le cadre d’une maintenance par exemple), il faut faire croire au nœud secondaire que le processus HEARTBEAT du nœud primaire est mort, il suffit donc de le stopper :

PRIMARY> rchertbeat stop

Sur le primary : Heartbeat va alors stopper les services associés aux haressources (drbd et mysql) puis va se libérer de l’adresse ip virtuelle.

Sur le secondary : le Heartbeat local va constater le décès du heartbeat primaire, va alors s’affecter l’adresse IP virtuelle, monter la partition drbd dans /data puis démarrer mysql  => le cluster a basculé.

2.5.2      FAIL BACK :

Pour revenir en arrière (« fail back » ó basculer du secondaire au primaire), il faut dans la même logique taper :

PRIMARY> rcheartbeat start

(attendre quelques instants par sécurité que heatbeat soit ok)

SECONDARY> rcheartbeat stop

(attendre quelques instants par sécurité pour être sur que le nœud PRIMAIRE a bien pris la main)

SECONDARY> rcheartbeat start ß on remet le SECONDARY node en observation.

Pour les mêmes raisons, tout a démarré sur le PRIMARY, tout a été stoppé sur le SECONDARY, la réplication reprend son cours normal.

3. Sauvegarde et restauration des données MySQL du CLUSTER

3.1       Introduction

Le cluster MySQL au sens de DRBD se résume à l’administration d’un serveur MySQL classique. Les données ne sont en effet présentes à un instant « t » que sur un serveur (le nœud DRBD actif) et en secours sur le serveur SLAVE MySQL.

Comme dans le cadre d’un serveur classique, le principe réside dans la réalisation d’un dump d’une base de données effectué base ouverte et active en s’assurant de la cohérence des données. Les tables stoquées par le moteur MyISAM seront verrouillées pendant ce backup et ne sont pas recommandées pour cela alors que les tables du moteur InnoDB ne le seront pas.

3.2       Sauvegarde

Le script /data/mysql/scripts/sauvegarde_full.sh permet de lancer un dump ds bases de données du Cluster en profitant des fonctionnalités transactionnelles de InnoDB pour en assurer la cohérence

Une transaction est ouverte avant de dumper puis est fermée une fois le dump terminé => Les données sont donc cohérentes.

Ce script est automatisé par la crontab et réalise les dumps dans /data/mysql/backups/

Remarque : Les dumps contiennent en fin de fichier l’information « – Dump completed on YYYY-MM-DD HH :MM :SS », une information qui peut être très intéressante dans le cadre d’un recovery.

Attention : les tables du moteur MyISAM ne seront pas cohérentes ! Si un programmeur persiste à utiliser ce moteur, il faudra utiliser le script /data/mysql/scripts/sauvegarde_full_MYISAM.sh mais les tables seront verrouillées pendant le dump, ce qui peut parfois s’avérer très gênant.

3.3       Restauration de données

3.3.1      Introduction

Définition :

Une restauration (ou « RESTORE ») consiste à rétablir les données d’une database à celles exactement présentent dans une sauvegarde (dump SQL dans notre cas).

Un recouvrement (ou « RECOVER ») consiste à rejouer la vie d’une database à partir d’un certain moment (celui d’un RESTORE généralement) jusqu’à un autre point (avant un crash, avant une erreur utilisateur, …)

Avant toute restauration, il faudra empêcher les utilisateurs externes d’accéder à vos databases, sous peine de corrompre les données. Pour cela, il faut ajouter le commutateur « skip-networking » dans la section « [MYSQLD] » de votre fichier de configuration globale « /etc/my.cnf ». Il ne faudra pas oublier d’enlever ce commutateur une fois la restauration terminée…

Le commutateur skip-networking comme son nom l’indique interdit les accès réseau (IP) et seules les opérations basées sur les sockets Unix sont autorisées, dont feront parti vos ordres de restauration en command line.

Plusieurs types de restauration de données peuvent être demandés :

-          Restauration totale : on parle de  « restauration totale ». Il s’agit de la restauration d’un dump précis. Cette restauration peut être restreinte à une base de données ou une table d’une base de données.

-          Restauration partielle sur erreur : (Point In Time Recovery) : Une bêtise à été commise par un utilisateur à une heure H, les utilisateurs demandent à ce que une base B soit restaurée à sa situation avant l’erreur utilisateur et au plus près de H

-          Restauration partielle après un crash : Un crash s’est produit. Il est demandé de restaurer une database au plus près possible d’avant le crash.

Une restauration « partielle » consiste en la restauration totale d’un fichier de sauvegarde (RESTORE) et l’application d’un journal de transactions DDL et DML (RECOVER) jusqu’à un certain point (un numéro de transaction ou une date & heure).

3.3.2      Restauration totale

C’est le cas le plus simple, celui où un utilisateur demande la restauration totale d’une base de données par l’injection d’un dump réalisé précédemment.

Imaginons dans ce cas que le dump ainsi pointé par l’utilisateur est /data/backups/mondump.sql.

-          Restauration d’une database « MABASE » sauvegarde par le dump « dump_de_ma_base.sql » :

> cd /data/backups/

> mysql  -uroot  <  dump_de_ma_base.sql

3.3.3      Restauration partielle

3.3.3.1         Introduction

Une restauration « partielle » ou « PITR (PointInTimeRecovery)» consiste en une restauration FULL (RESTORE) et en l’application des instructions DDL et DML (RECOVER) jusqu’à une certaine date, heure ou encore un certain numéro de transaction SQL.

Une restauration (RESTORE) n’est possible que si l’on dispose du dump contenant les données exigées (un dump est réalisé à heures fixes ou sur demandes, …) pour une date/heure précise.

Il est possible d’effectuer après cela un RECOVER en fonction de diverses situations (erreur DBA ou erreur utilisateur, crash d’un fichier, crash server, …), ceci afin de remonter la database au plus près de la réalité des données avant l’erreur critique.

MySQL permet d’enregistrer les ordres DDL et DML utiles adressées à votre base de données sous la forme d’un format de fichiers binaires appelés « binary logs ».

L’activation de cette trace SQL se fait par ajout du commutateur « log-bin » dans my.cnf et d’un ensemble de paramètres de gestion des logs binaires (voir section 4.1.1).

mysqlbinlog est un utilitaire permettant de lire les fichiers de logs binaires et d’en exporter les informations sous un format textuel afin de les « rejouer » sur une base de données après un « RESTORE ».

3.3.3.2         Restauration totale au plus près d’avant un crash

Cas classique : Une sauvegarde FULL d’une database MABASE a été effectuée le matin à 00h00 sous la forme d’un dump SQL exécuté par myssqldump.

A 06h00, un fichier composant tout ou partie d’une des databases InnoDB présente une erreur d’intégrité. La database est alors inaccessible.

Méthode :

-          Fermer l’accès du serveur aux utilisateurs

Ajouter « skip-networking » dans /etc/my.cnf + rcmysql restart

-          Détruire la database

> mysql –uroot   -e ‘drop database dbname ; ’

-          Restaurer le dump SQL (au sens de mysqldump) le plus récent possible.

> mysql  –uroot   <  /data/mysql/backups/dump_dbname_YYYYMMDD_HHIISS.sql

-          Appliquer les ordres DDL et DML des journaux binaires à partir de la date de génération du dump

> mysqlbinlog  /data/mysql/logs/binary/binarylog.*

–database=dbname ß recover restreint à la database « dbname »

–start-datetime=”2010-12-29 09:57:23″ ß date de fin du dump

–to-last-log ß jusqu’à la fin du dernier log binaire disponible

–result-file=/tmp/ordres_a_rejouer.sql

Remarque : la date de fin du dump se trouve dans le dump sql de la sauvegarde Full, en bas de fichier.

Remarque : mysqlbinlog va ensuite lire les logs binaires et en extraire un contenu textuelle d’ordres DDL et / ou DML, ce fichier est indiqué par –result-file=…. Il faudra appliquer ces logs SQL exactement de la même façon que l’on applique un DUMP :

> mysql  -uroot   <   /tmp/ordres_a_rejouer.sql

-          Ouvrir l’accès du serveur aux utilisateurs

Commenter « skip-networking » dans /etc/my.cnf + rcmysql restart

Attention : un PITR à une heure près est risqué car, en une seule seconde, plusieurs instructions peuvent altérer la database, il n’est donc pas certain que une heure à la seconde près soit une méthode « sure » pour pratiquer un Recover dans le temps.

Il est plus sur d’indiquer un numéro de transaction  (« log position » en MySQL).  Ce numéro est identifié par « MASTER_LOG_POS » qui  trouve en haut de chaque dump dans le champ comme par exemple :

– CHANGE MASTER TO MASTER_LOG_FILE=’binarylog.000547′, MASTER_LOG_POS=106;

Ici, l’ordre de recover serait :

mysqlbinlog  /data/mysql/logs/binary/binarylog.*

–database=dbname

–start-position  =”107″

–to-last-log

–result-file=/tmp/ordres_a_rejouer.sql

3.3.3.3         Restauration totale, Recouvrement partiel (PITR)

Comme dans le point précédent, il faut d’ahabord restaurer le dump de la dernière sauvegarde FULL.

Ensuite, il faut pratiquer un recover, mais pas jusqu’au au bout.

a.       Exemple 1 : Indication horaire

Par exemple, à 12:00:00 un programme a détruit des tables, les applis ne fonctionne plus et on demande de restaurer à 11 :59 :00.

La procédure est strictement identique à celle d’un recover total sauf que le commutateur « –to-last-log » doit être remplacé par « –end-datetime=”2010-12-29 11:59:00″ »

mysqlbinlog

/data/mysql/logs/binary/binarylog.*

–database=dbname

–start-position  =”107″

–end-datetime=”2010-12-29 11:59:00″

–result-file=/tmp/ordres_a_rejouer.sql

Comme indiqué dans le point précédent, cette méthode est incertaine car en une seconde (11 :59 :00) il peut se passer plusieurs transactions et on peut ainsi rejouer les ordres SQL destructeurs rendant le recovery inutile ou au contraire rater les ordres qui se sont joués en fait la seconde d’après …

b.       Exemple 2: Indication fonctionnelle :

L’utilisateur vous indique que un ordre « drop table ma_table » a été passé par erreur, provoquant la catastrophe qui a suivi.

Il faut alors repérer dans les logs binaires le LOG_POS de cette ordre pour demander un recover jusqte avant celui-ci.

mysqlbinlog binarylog.* | grep -B 5 -i “DROP TABLE MA_TABLE”

… (5 lignes ‘B’efore)

> at 2627

> 101228 16:39:09 server id 1  end_log_pos 2654

> drop table matable

Dans cet exemple, le dernier LOG_POS AVANT le drop est le « 2654 », il faut donc pratiquer un recover jusqu’à ce numéro inclus :

mysqlbinlog

/data/mysql/logs/binary/binarylog.*

–database=dbname

–start-position  =”107″

–stop-position=”2654″

–result-file=/tmp/ordres_a_rejouer.sql

Pour résumer, s’il est IMPOSSIBLE de connaitre un LOG_POSITION (ou s’il n’y a aucunne embiguité mais c’est assez rare), on préférera les Recover à base de STOP-POSITION plustôt que ceux à base de END-DATETIME.

4.  Annexes

4.1       Fichiers de configuration MySQL

4.1.1      Configuration sur les nœuds du cluster DRBD

/etc/my.cnf

[client]

port                            = 3306

socket                          = /data/mysql/run/mysql.sock

[mysqld]

port                            = 3306

socket                          = /data/mysql/run/mysql.sock

server-id                       =1

skip-external-locking

skip-ndbcluster

default-storage-engine=INNODB

# LOGGING #

log_error                       = /data/mysql/logs/text/error.log

general_log                     = ON

general_log_file                = /data/mysql/logs/text/general_log_file.log

log_slow_queries                = ON

slow_query_log_file             = /data/mysql/logs/text/slow_queries.log

long_query_time                 = 4

binlog_format                   = ROW

max_binlog_size                 = 100M

log_bin_index                   = /data/mysql/logs/binary/index.log

log-bin                         = /data/mysql/logs/binary/binarylog.rotation

expire_logs_days                = 15

binlog-ignore-db                = mysql

binlog-ignore-db                = test

# Parametrages myISAM #

datadir                         = /data/mysql/datafiles/databases

key_buffer_size                 = 16M

max_allowed_packet              = 1M

table_open_cache                = 64

sort_buffer_size                = 512K

net_buffer_length               = 8K

read_buffer_size                = 256K

read_rnd_buffer_size            = 512K

myisam_sort_buffer_size         = 8M

# Parametrage InnoDB #

innodb_data_home_dir            = /data/mysql/datafiles/innodb_default

innodb_data_file_path           = ibdata01:50M:autoextend

innodb_file_per_table           = 1

innodb_log_group_home_dir       = /data/mysql/logs/undo

innodb_buffer_pool_size        = 8192M

innodb_additional_mem_pool_size= 2M

[safe_mysqld]

log-error                       = /data/mysql/logs/text/mysqld.log

socket                          = /data/mysql/run/mysql.sock

[mysqldump]

socket                          = /data/mysql/run/mysql.sock

quick

max_allowed_packet              = 16M

[mysql]

no-auto-rehash

[myisamchk]

key_buffer_size                 = 20M

sort_buffer_size                = 20M

read_buffer                     = 2M

write_buffer                    = 2M

[mysqlhotcopy]

interactive-timeout

[mysqld_multi]

mysqld                          = /usr/bin/mysqld_safe

mysqladmin                      = /usr/bin/mysqladmin

log                             = /data/mysql/logs/text/mysqld_multi.log

4.1.2      Sur le serveur MySQL SLAVE

/etc/my.cnf

[client]

port                            = 3306

socket                          = /data/mysql/run/mysql.sock

[mysqld]

port                            = 3306

socket                          = /data/mysql/run/mysql.sock

server-id                       = 10

skip-external-locking

default-storage-engine=INNODB

log_error                       = /data/mysql/logs/text/error.log

general_log                     = ON

general_log_file                = /data/mysql/logs/text/general_log_file.log

slow_query_log                  = ON

slow_query_log_file             = /data/mysql/logs/text/slow_queries.log

long-query-time                 = 1

relay-log                       =/data/mysql/logs/binary/relaybinlog.rotation

relay-log-index                 =/data/mysql/logs/binary/relaybinlog.index

relay-log-info-file             =/data/mysql/conf/relay-log.info

master-info-file                =/data/mysql/conf/master.info

datadir                         = /data/mysql/datafiles/databases

key_buffer_size                 = 16M

max_allowed_packet              = 1M

table_open_cache                = 64

sort_buffer_size                = 512K

net_buffer_length               = 8K

read_buffer_size                = 256K

read_rnd_buffer_size            = 512K

myisam_sort_buffer_size         = 8M

innodb_data_home_dir            = /data/mysql/datafiles/innodb_default

innodb_data_file_path           = ibdata01:50M:autoextend

innodb_file_per_table           = 1

innodb_log_group_home_dir       = /data/mysql/logs/undo

[safe_mysqld]

log-error                       = /data/mysql/logs/text/mysqld.log

socket                          = /data/mysql/run/mysql.sock

[mysqldump]

socket                          = /data/mysql/run/mysql.sock

quick

max_allowed_packet              = 16M

[mysql]

no-auto-rehash

[myisamchk]

key_buffer_size                 = 20M

sort_buffer_size                = 20M

read_buffer                     = 2M

write_buffer                    = 2M

[mysqlhotcopy]

interactive-timeout

[mysqld_multi]

mysqld                          = /usr/bin/mysqld_safe

mysqladmin                      = /usr/bin/mysqladmin

log                             = /data/mysql/logs/text/mysqld_multi.log

4.2       Fichiers de configuration DRBD

/etc/drbd.conf

global {

usage-count yes;

# minor-count dialog-refresh disable-ip-verification

}

common {

protocol C;

handlers {

pri-on-incon-degr “/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f”;

pri-lost-after-sb “/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f”;

local-io-error “/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f”; # fence-peer “/usr/lib/drbd/crm-fence-peer.sh”;

# split-brain “/usr/lib/drbd/notify-split-brain.sh root”;

# out-of-sync “/usr/lib/drbd/notify-out-of-sync.sh root”;

# before-resync-target “/usr/lib/drbd/snapshot-resync-target-lvm.sh -p 15 — -c 16k”;

# after-resync-target /usr/lib/drbd/unsnapshot-resync-target-lvm.sh;

}

startup {

# wfc-timeout degr-wfc-timeout outdated-wfc-timeout wait-after-sb;

}

disk {

# on-io-error fencing use-bmbv no-disk-barrier no-disk-flushes

# no-disk-drain no-md-flushes max-bio-bvecs

on-io-error detach;

}

net {

# sndâf-size rcvbuf-size timeout connect-int ping-int ping-timeout max-buffers

# max-epoch-size ko-count allow-two-primaries cram-hmac-alg shared-secret

cram-hmac-alg “sha1″;

shared-secret “drbd-sql”;

# after-sb-0pri after-sb-1pri after-sb-2pri data-integrity-alg no-tcp-cork

}

syncer {

# rate after al-extents use-rle cpu-mask verify-alg csums-alg

rate 800M;

al-extents 257;

}

}

resource cluster0{

protocol C;

net {

cram-hmac-alg “sha1″;

shared-secret “drbd-sql”;

}

on sql-primaire {

device /dev/drbd0;

disk /dev/sda4;

address 192.168.168.1:8888;

meta-disk internal;

}

on sql-secondaire {

device /dev/drbd0;

disk /dev/sda4;

address 192.168.168.2:8888;

meta-disk internal;

}

}

4.3       Fichiers de configuration de HeartBeat

/etc/ha.d/ha.cf

debugfile /var/log/ha-debug.log

logfile /var/log/ha.log

logfacility     local0

keepalive 2

deadtime 15

warntime 8

initdead 30

# interfaces reseaux en multicast pour envoyer les battements de coeur

mcast bond0 225.0.0.1 694 1 0

mcast eth2  225.0.0.1 694 1 0

# pas de retour-arriere automatique en cas de panne, trop dangereux

auto_failback off

# quels sont les noeuds concernes par le cluster heartbeat

node sql-primaire

node sql-secondaire

# on verifie que le host peut joindre l’interface publique

ping 192.168.13.253

deadping 5

respawn hacluster /usr/lib64/heartbeat/ipfail

apiauth ipfail gid=haclient uid=hacluster

/etc/ha.d/haresources.cf

otsql-primaire drbddisk::cluster0 Filesystem::/dev/drbd0::/data::ext3 192.168.13.100 mysql

/etc/ha.d/resource.d/mysql (non présent après l’installation)

#!/bin/bash

#

# This script is inteded to be used as resource script by heartbeat

#

# Mar 2006 by Monty Taylor

#

###

. /etc/ha.d/shellfuncs

case “$1″ in

start)

res=`/etc/init.d/mysql start`

ret=$?

ha_log $res

exit $ret

;;

stop)

res=`/etc/init.d/mysql stop`

ret=$?

ha_log $res

exit $ret

;;

status)

if [[ `ps -ef | grep '[m]ysqld’` > 1 ]] ; then

echo “running”

else

echo “stopped”

fi

;;

*)

echo “Usage: mysql {start|stop|status}”

exit 1

;;

esac

exit 0

CopyLeft:

Ce document est issu d’un document d’entreprise interne dans la mise en place d’un cluster MySQL HA et ce, dans de rééelles conditions de production.

RMAN permet d’éffectuer la sauvegarde, à froid comme à chaud, de vos bases oracle, en mode total, incrémentiel et/ou cumulatif (nous verrons plus loin ces notions).

Comme indiqué dans le chapitre REFERENTIEL RMAN, RMAN peut utiliser les fichiers de contrôle d’une base de données pour y stoquées les informations utiles pour ses sauvegardes (et donc ses restaurations), mais cela pose de nombreux problèmes en cas de perte de ceux ci. L’altéernative est de stoquer le catalogue dans une database prévue à cet effet (ce que nous vous conseillons).

1 – Nomenclature:

RMAN peut éffectuer de simples copies des fichiers de données, on parle alors de “IMAGE COPY”, ou de gérer l’ensemble des copies qu’il éffectue pour vous dans un format propriétaire nommé “BACKUP SET”.

Une ImageCopy est exactement la même chose que si vous aviez copié des fichiers par l’OS : c’est de loin la meilleure option.

Le BackupSet en revanche permet de ne sauvegarder que les blocs oracles utilisés dans les datafiles, ce qui allège considérablement le poids des sauvegardes avec un rapport de 1/5, ce qui est loin d’être négligeable. De plus, un BackupSet peut être découpé logiquement en plusieurs parties nommées “BACKUP PIECES” ceci pour répondre à des problématiques de limite de stockage (un DBF de 10Go sur une bande de 4Go par exemple).

Rappel: Que cela soit avec RMAN ou un autre outil de sauvegarde, il n’y a pas de miracle, une sauvegarde à chaudd’une database ne peut s’éffectuer QUE si celle si l’archivage des fichiers journaux (archivelogs) est activé, sinon cela n’est pas possible. Une sauvegarde “à chaud”, avec ou sans RMAN, est de toute façon incohérente, il conviendra d’appliquer les journaux archivés aux fichiers de données restaurés pour obtenir une sauvegarde “cohérente”.

2 – Sauvegarde non incrémentale :

Comme vous pouvez vous en douter, BACKUP est l’instruction de RMAN qui va vous permettre d’effectuer une sauvegarde de votre base de données complète ou partielle, full ou incrémentale. Elle vous permet de sauvegarder un fichier de données, un tablespace, la database entière, le spfile et les fichiers de contrôles, les journaux et journaux archivés.

La syntaxe est assez simple :  RMAN> BACKUP <ordre> <options>

Les [] symbolisent ici des éléments non obligatoires, les caractères gras les commutateurs les plus habituels en production.

2.1 – Ordres de la commande BACKUP :

[ incremental level <n> [ cumulative] ]

permet les sauvegardes incrémentales de niveau 0 ou 1, avec l’option de cumuler les sauvegardes pour l’amélioration des performances à la restauration

[ validate ]

Doit – on vérifier la sauvegarde après sa génération ?

[ as [ copy | [compressed] backupset ]

Quel est le type de sauvegarde ? (“backup set” recommandé)

[ database | tablespace <ts_name> | datafile <df_name> | current controlfile | spfile ]

que sauvegarder ?

[ archivelog <cible> ]

faut il sauvegarder les archivelogs et où ?

2.2 – Options de la commande BACKUP :

[ include current controlfile ]

généralement à faire, sauve si sauvegarde automatique du CTL file déjà prévue (voir plus loin)

[ plus archivelog ]

à effectuer en mode archivelogs dans le cas des sauvegardes à chaud car c’est indispensable pour obtenir une database cohérente après restauration.

[ delete [ all ] input ]

généralement à effectuer : détruit les archivelogs qui ne sont plus nécessaires

[ format = '<format>' ]

format de la sauvegarde (voir plus loin)

[ tag = '<libelle_de_marqueur>' ]

Très utile : ajouter un tag (marqueur informatif) à une sauvegarde. Il sera possible d’interroger RMAN sur ces tags.

[ not backed up <clause>]

[ ALL | FROM TIME <time> | UNTIL TIME <time> | TIME BETWEEN <t1> AND <t2> ]

Exemples d’utilisation:

Fait un backup de la database et valide que les fichiers sont restaurables:

RMAN> backup validate database tag='full_20080701_2015' plus archivelog delete input;

Fait un backup de la database et des archivelogs si elles n’ont pas été sauvegardées au moins 3 fois:

RMAN> backup database plus archivelog not backed up since 3 times;

Fait un backup des TableSpaces ‘datats’ et ‘indexts’ et backup également les controlfiles et spfiles.

RMAN> backup tablespace datats, indexts include current controlfile;

Fait un backup du datafile #7:

RMAN> backup datafile 7, '/data/madatabase/datafiles/mondbf01.dbf';

Remarque 1 :

Une sauvegarde RMAN est une sauvegarde (intelligente) des fichiers composants la base de données (entre autre les datafiles). Ces fichiers, quel que soit le mode de sauvegarde (database, datafile, …) sont copiés les uns après les autres, il est don cfort à parier que, si la base de données “vie” un minimum, que les fichiers soient positionnés à des SCN différents lors de leur sauvegarde.

Les journaux et les journaux archivés sont alors indispensables lors de la restauration car il faudra pratiquer un recovery après restauration des datafiles pour rendre l’ensemble de la base “cohérente” (cad toutes les en-têtes des fichiers sont de même SCN).

Les commutateurs “PLUS ARCHIVELOG” sont alors strictement nécessaires, nes les oubliez pas !

Remarque 2 : Il est possible de sauvegarder manuellement les archivelogs par la commande “BACKUP ARCHIVELOG ALL’”.

Remarque 3: Nous verrons par la suite qu’il est souvent inutile de préciser certains commutateurs car ceux ci font partie d’une conguration globale de RMAN et sont donc inclus par défaut.

3 – Sauvegarde incrémentale :

Note: Cette option n’existe quà partir du niveai de licence “Enterprise”.

3.1 – Incrémentale basée sur les traçage de blocs indiqué par Oracle :

La sauvegarde incrémentale au sens de RMAN peut appuyer sur la technologie de traçage des blocs modifiésd’une instance Oracle par le moteur de base de données.  Cette option activée indique au moteur de base de données qu’il doit spécifier dans un fichier particulier l’ensemble des blocs modifiés depuis l’instant T. Cette liste sera consultée par RMAN dans le cadre d’une sauvegarde incrémentale et celui-ci n’ira alors sauvegardé que les blocs marqués par Oracle comme modifiés dans ce fichier de trace.

Syntaxe:

SQL> database enable block change tracking using file '<chemin_fichier>';

3.2 – Incrémentale basée sur les traçages de blocs non indiqués par Oracle :

Le traçage de blocs Oracle par le moteur de base de données comme indiqué dans 3.1) n’est pas obligatoire pour éffectuer une sauvegarde incrémentale avec RMAN mais, dans ce cas là, celui-ci ne peut pas connaitre la liste exhaustive des blocs modifiés et est obligé de parcourir tous les blocs d’un tablespace afin de déterminer quels sont les blocs modifiés depuis sa dernière sauvegarde.

Le résultat sera exactement le même qu’avace le traçage de blocs Oracle par le moteur de base de données mais les performances s’écroulent : n’hésitez pas à utiliser le traçage de blocs Oracle par le moteur de base de données !

3.3 – Niveau de sauvegarde :

Une sauvegarde incrémentale au sens de RMAN possède un NIVEAU. Le niveau d’une sauvegarde incrémentale indique à RMAN quelle est la sauvegarde de base que celui-ci doit considérer pour évaluer le “delta” avec une situation actuelle à sauvegarder.

- NIVEAU 0 : Même si la sauvegarde est dite incrémentale, le niveau 0 indique en fait à RMAN que tout doit être sauvegardé, même si RMAN ne considère pas une telle sauvegarde comme FULL, elle contient pourtant tous les blocs de la base de données et est restaurable.

- NIVEAU 1 : Si une incrémentale est de niveau 1, alors RMAN ne sauvegardera QUE la différence avec la dernière sauvegarde équivalente de niveau 1 ou de niveau 0 : C’est une sauvegarde différentielle.

Le principe étant de faire régulièrement des sauvegardes de niveau 0 et, périodiquement, des sauvegardes de niveau 1 alors beaucoup plus rapides à éffectuer.

3.4 – Sauvegarde cumulative

Une sauvegarde cumulative est une sauvegarde de niveau 1 qui contient tous les blocs modifiés depuis la dernière sauvegarde de niveau 0, même si des sauvegardes intermédiaires de niveau 1 ont été éffectées.

Ce type de sauvegarde consiste à demander à RMAN de repérer tous les blocs modifiés depuis la dernière sauvegarde de niveau 0, puis de les sauvegarer, une opération qui peut s’avérer lourde si la date de la dernière sauvegarde de niveau 0 est ancienne et que l’activité de la database est importante. Pour réduire ce phénomène, on pourra faire appel au pointage des blocs modifiés par le moteur de base de donnés Oracle et non par RMAN comme indiqué dans 3.1).

L’avantage est évidement : les opérations de restaurations sont beaucoup plus rapides puisque aucunne sauvegarde de niveau 1 non cumulative n’est à appliquer.

La syntaxe générale d’une sauvegarde incrémentale est :

RMAN> BACKUP INCREMENTAL LEVEL [0 | 1 ] [ CUMULATIVE ] <ordre> <option>

1.1       Introduction

Fail2Ban est un utilitaire permettant de surveiller divers logs fichier, de repérer à l’intérieur des messages critiques synonymes de tentatives de hack et à minima d’automatiser le bannissement des adresses IP concernées.

Fail2Ban permet de se prémunir des attaques par bruteForce sur les principaux logiciels serveurs (sshd, pop3d, imapd, httpd, ftpd, …), d’automatiser un ban sur une durée D1 et d’automatiser le déban au bout d’un temps D2.

Le fichier fail2ban.zip (joint l’article RTFM de ce même document) contient la version 0.8.4 de jail2Ban.

Les updates de fail2Ban peuvent se trouver ici : http://sourceforge.net/projects/fail2ban/files/

1.2       Prérequis

fail2ban est un script écrit en Python, il ne nécessite aucun outil de compilation.

La version de Python exigée (à minima) est 2.3

Les librairies de développement de Pyhton sont nécessaires au déploiement de fail2ban (incluses dans toutes les distributions)

2.  Installation

-          Décompresser l’archivefail2ban dans un dossier temporaire D

-          Entrer dans le dossier D et taper la commande « python   setup.py   install »

-          Créer le fichier /etc/init.d/fail2ban tel que :

#! /bin/sh

# Copyright (c) XXX.

# All rights reserved.

#

# Author:XXX

# Please send feedback to http://sss/

#

# /etc/init.d/fail2ban

#

### BEGIN INIT INFO

# Provides:          fail2ban

# Required-Start:    $syslog $network $dovecot

# Required-Stop:

# Default-Start:     3 5

# Default-Stop:      0 1 2 6

# Description:       Fail2Ban Server

### END INIT INFO

. /etc/rc.status

# Reset status of this service

rc_reset

case “$1″ in

start)

echo -n “Starting FAIL2BAN ”

/usr/local/bin/fail2ban-client -v -c /etc/fail2ban start

echo “Etat des tables ”

/usr/sbin/iptables –list

;;

stop)

echo -n “Stopping FAIL2BAN ”

/usr/local/bin/fail2ban-client -v -c /etc/fail2ban stop

echo “Etat des iptables ”

/usr/sbin/iptables –list

;;

restart)

$0 stop

$0 start

rc_status

;;

status)

echo -n “Statut FAIL2BAN ”

/usr/local/bin/fail2ban-client -v -c /etc/fail2ban status

echo “Etat des tables ”

/usr/sbin/iptables –list

;;

*)

echo “Usage: $0 {start|stop|restart|status}”

exit 1

;;

esac

rc_exit

-          Taper les commandes :

• chmod +x /etc/init.d/fail2ban
• chkconfig    — add   fail2ban   35
• ln   –s   /etc.init.f/fail2ban   /usr/sbin/fail2ban

3.  Configuration

3.1       Configuration de base

3.1.1      Fichier « /etc/fail2ban/fail2ban.conf »

Voici les notions importantes à modifier, le reste peut rester en commentaires ou en valeurs par défaut :

3.1.2      Fichier « /etc/fail2ban/jail.conf »

3.1.2.1         Configuration générale

Ce fichier contient une configuration par défaut de fail2ban (section « [DEFAULT] ») telle que :

Les autres sections de ce fichier de configuration sont des  « JAILS » (prisons).

Les JAILS indiquent la façon dont on va observer un fichier de log particulier, pour observer quel type de hack éventuel décris par des expressions régulières et quelles actions éventuelles seront alors à éffectuer (banissement temporaire d’IP ou autre), les JAILS sont décrits dans 3.1.2

3.1.2.2         Configuration des « JAILS »

Une JAIL est la description du besoin d’observer le contenu d’un fichier de log et de définir des actions en cas de tentative de hack. Les JAILS sont décrites dans le fichier /etc/fail2ban/jail.conf décrit en 3.1.2.

-          JAIL standard pour SSH :

-          Construction d’une JAIL personalisée (exemple : DOVECOT pour mySQL) :

Dovecot est souvent utilisé comme serveur POP3/IMAP4, il est la pluspart du temps couplé avec mySQL dans lequel il trouvera la base utilisateurs (logins et passwords). Cependant, il n’existe pas de JAIL standard préconfigurée. Il faut donc faire tracer l’authentification de Dovecot dans un fichier précis, choisissons « /var/log/dovecot.log »,.

-          Paramétrage de DoveCot

• Editer « /etc/dovecot/dovecont.conf » et fixer « log_path » à «  /var/log/dovecot.log », puis relancer Dovecot

-          Paramétrage de fail2ban (ajout d’une JAIL)

-          Paramétrage d’un Filtre « dovecot » (voir en 3.1.2.3)

-          L’action choisie dans cet exemple est la même que pour un la JAIL « ssh-iptables », celle-ci est donc déjà écrite il n’y a rien à faire, sinon il aurait fallu créer une action comme en 3.1.2.4.

3.1.2.3         Configuration d’un filtre

Les « filtres » de fail2ban sont dans le dossier « /etc/fail2ban/filter.d/ ».

Il existe un fichier unique par nom de filtre déclaré danes les JAILS, par exemple « /etc/fail2ban/filter.d/sshd.conf » pour la JAIL « ssh-iptables » décrite en 3.1.2.2.

Un filtre est principalement caractérisé par une expression régulière plus ou moins complexe décrite par le paramètre « failregex » du fichier de filtre. Si l’expression régulière « match » sur une nouvelle ligne dans le fichier de log d’une JAIL, alors fail2ban considèrera qu’une tentative de hack a été réalisée.

-          Exemple : Expression régulière du filtre sshd :

-         

failregex = ^%(__prefix_line)s(?:error: PAM: )?Authentication failure for .* from <HOST>\s*$

^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from <HOST>\s*$

^%(__prefix_line)sFailed (?:password|publickey) for .* from <HOST>(?: port \d*)?(?: ssh\d*)?$

^%(__prefix_line)sROOT LOGIN REFUSED.* FROM <HOST>\s*$

^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST>\s*$

^%(__prefix_line)sUser \S+ from <HOST> not allowed because not listed in AllowUsers$

^%(__prefix_line)sauthentication failure; logname=\S* uid=\S* euid=\S* tty=\S* ruser=\S* rhost=<HOST>(?:\s+user=.*)?\s*$

^%(__prefix_line)srefused connect from \S+ \(<HOST>\)\s*$

^%(__prefix_line)sAddress <HOST> .* POSSIBLE BREAK-IN ATTEMPT!*\s*$

^%(__prefix_line)sUser \S+ from <HOST> not allowed because none of user’s groups are listed in AllowGroups$

-          Exemple : Création d’un filtre « dovecont » pour la JAIL « dovecot »

La technique consiste à repérer dans le fichier de log (ici « /var/log/dovecot.log ») une ligne représentant un échec d’authentification puis, à l’aide des expressions régulières, la renseigner dans le paramètre failregex un fichier « /etc/fail2ban/filter.d/dovecot.conf » à créer.

Le fichier /var/log/dovecot.log contient des erreurs du style :

« dovecot: Oct 05 15:24:46 Info: auth-worker(default): sql(unUserBidon,192.168.10.19): unknown user »

L’expression régulière symbolisant cette chaine peut être par exemple :

« sql.*,<HOST>\).*unknown user »

Le paramètre <HOST> représente ici l’adresse IP que fail2ban peut récupérer dynamiquement dans cette expression régulière et qui sera passée en paramètre à son « action » correspondante et permettra un ban par iptables ou autre.

Le filtre de dovecot est donc le fichier « « /etc/fail2ban/filter.d/dovecot.conf » tel que :

# Fail2Ban configuration file

#

# Author: XXX

# Modified by: XXX

#

# $Revision: 1 $

#

[Definition]

# Option:  failregex

# Notes.:  regex to match the password failures messages in the logfile. The

#          host must be matched by a group named “host”. The tag “<HOST>” can

#          be used for standard IP/hostname matching and is only an alias for

#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)

# Values:  TEXT

#

#failregex = LOGIN FAILED, .*, ip=\[<HOST>\]$

# exemple:

# dovecot: Oct 04 17:59:00 Info: auth(default): pam(contact@hotel-lesvoyageurs.com,86.193.160.20): pam_authenticate() failed: Authentication failure

#failregex  = pam.*,<HOST>\).*failure

# exemple:

# dovecot: Oct 05 15:21:13 Info: auth-worker(default): sql(xaxaxa,192.168.10.19): unknown user

failregex  = sql.*,<HOST>\).*unknown user

ignoreregex =

# Option:  ignoreregex

# Notes.:  regex to ignore. If this regex matches, the line is ignored.

# Values:  TEXT

#

ignoreregex =

Il suffit de relancer fail2ban pour prendre en compte ces modifications.

Remarque) Pour vérifier la liste des IP(s) temporairement bannies par fail2ban, il faut utiliser la commande « iptables   –list ».

3.1.2.4         Configuration d’une action

Ce document ne documente pas cette section car les actions existantes par défaut dans fail2ban sont à priori largement suffisantes.

Les actions se trouvent dans le dossier « /etc/fail2ban/actions.d ».

Les paramètres récupérés dynamiquement dans les expressions régulières des filtres sont récupérable dynamiquement dans les scripts « actions ».  S’inspirer des scripts existant pour en créer de nouveaux.

1.1       MySQL NDB , un cluster de données orienté « mémoire »

MySQL Cluster est dit un cluster « in memory », cela signifie que la plupart des éléments sont, pour des raisons de performance, chargés en mémoire et que ceux-ci sont régulièrement écris sur disque selon divers critères. Il est donc très important que les nœuds de stockage du cluster soient pourvus de beaucoup de mémoire.

Le cluster MySQL ne dispose pas de système de fichier partagé (via SAN, …) comme un cluster au sens « classique » du terme mais dispose d’éléments de dialogue réseau qui lui permet de synchroniser les données du cluster au sein de tous ses nœuds. Les données d’un cluster MySQL sont stockées sur des disques locaux des différents serveurs du cluster et les données partagées sont « répliquées » par des processus internes entre les différentes composantes du cluster.

L’élément fondamental du cluster MySQL est donc la capacité à traiter rapidement et efficacement des requêtes réseau sous le protocole TCP/IP (cartes Ethernets gigabits requises, sockets SCI recommandés).

La documentation indique des options permettent de faire en sorte que le Cluster mySQL écrive sur disque, mais celle-ci sont très consommatrices en ressources et peuvent dégrader de façon significative les performances.

1.2       Les « nœuds » (ou « nodes ») : composantes de base de MySQL-Cluster

Un élément serveur logiciel élémentaire de mySQL Cluster se nomme un « node » (ou « nœud »). Un node est un élément logique, aussi, il peut exister plusieurs nodes sur une machine physique composante d’un cluster mySQL.

La nature d’un Un node peut être de divers nature :

-          Node de STOCKAGE (NDB) :

Le node de stockage (ou node NDB du nom du moteur de cluster « NDBENGINE ») est un nœud chargé de gérer, avec l’ensemble des autres nodes de même nature, la répartition des données sur l’ensemble des nodes de stockage du cluster, d’en assurer la réplication inter-nodes afin de garantir la disponibilité des datas et enfin de gérer les demandes d’accès aux données.

Au vue des forts besoins en mémoire du Cluster mySQL, il est recommandé d’installer des versions 64bits des nœuds NDB afin de passer la barrière fatidique des 3096Go de mémoire maximale sur une 32bits linux.

Dans notre exemple (Cluster « CLUSTER») nous utiliserons 2 nœuds NDB situés en

• 10.20.0.29 (SITSQL01) [ machine physique ]
• 10.20.0.30 (SITSQL02) [ machine physique ]

Les nodes NDB sont au minimum de 2 dans un cluster mySQL.

-          Node MANAGER  (MGM):

Les nodes MGM (ou « Manager) sont les nœuds du cluster chargés en permanence d’informer les autres nœuds de la configuration du cluster (où sont les nœuds et quelles sont leur nature et leur état, …) et de son rythme de vie (quelles sont les demandes de synchronisations, …)

Dans notre exemple (Cluster « CLUSTER») nous utiliserons 2 nœuds MGM situés en

• 10.20.0.27 [ machine Xen ]
• 10.20.0.28 [ machine Xen ]

Les nodes MGM sont au minimum de 1 dans un cluster mySQL (2 recommandés).

-          Node SQL (SQL):

L’accès aux données stoquées sur les nodes NDB ne se fait pas de façon standard, comme pour un serveur mySQL autonome, il faut utiliser un API spécifique dit « NDB API ».

Dans le but de rendre compatible des applications écrites pour des serveurs autonomnes, il faut alors ajouter au cluster des nodes dits « SQL » qui sont des interfaces entre les API clientes standards et les nodes NDB.

Dans notre exemple (Cluster « XXX ») nous utiliserons 2 nœuds MGM situés en

• 10.20.0.25  [ machine Xen ]
• 10.20.0.26  [ machine Xen ]

Les nodes SQL sont au minimum de 1 dans un cluster mySQL (2 recommandés).

Dans une production, un cluster mySQL est donc composé à minima de 6 nodes (2 SQL, 2 MGM, 2 NDB) répartis sur 6 machines différentes dans un souci de haute disponibilité des données et de leur accès.

Notons que le cluster au sens de mySQL ne garanti pas la répartition de charge au sein des nodes SQL, il faudra se munir d’outils annexes (HAProxy, LVS/KeepAlive, etc.) pour cela.

Remarque : Dans le cas du cluster XXXX, voici les adresses contactables :

• Load balance : sql0.site.fr (serveur à utiliser par les applicatifs)
• Nœud 1 : sql1.site.fr

• Nœud 2 : sql12.site.fr

2.  Installation

2.1 Introduction

Les méthodes d’installation sont basées sur l’exploitation des outils d’installation disponibles sur une openSuSE 11.3 (x86_64).

2.2       Les packages nécessaires

Sur les nœuds MGM :

-          libmysqlclient16

-          libmysqlclient_r16

-          libmysqlclusterclient16

-          libmysqlclusterclient_r16

-          libmysqld0

-          libqt4-sql-mysql

-          mysql-cluster-client

-          mysql-cluster-ndb-management

-          mysql-cluster-ndb-tools

Sur les nœuds SQL :

-          libmysqlclient-devel

-          libmysqlclient16

-          libmysqlclient_r16

-          libmysqlclusterclient16

-          libmysqlclusterclient_r16

-          libmysqlcppconn-devel

-          libmysqlcppconn1

-          libmysqld-devel

-          libmysqld0

-          libqt4-sql-mysql

-          mysql-cluster

-          mysql-cluster-client

Sur les nœuds NDB :

-          libmysqlclient16

-          libmysqlclient_r16

-          libmysqld0

-          libqt4-sql-mysql

-          mysql-cluster-ndb-storage

-          mysql-cluster-ndb-tools

-          mysql-community-server

-          mysql-community-server-client

2.3       Fonctionnalités hors distribution

2.3.1      Introduction

Pour une correcte gestion de l’annulation d’un post traitement dans une procédure stockée ou un trigger, nous avons besoin d’ajouter une fonctionnalité supplémentaire livrée la librairie « lib_mysqludf_udf.so » téléchargeable ici : http://www.mysqludf.org/lib_mysqludf_udf/lib_mysqludf_udf_0.0.3.tar.gz.

-          Cette librairie est écrite en langage C, il convient d’installer gcc ainsi que les headers mySql (package libmysqlcppconn-devel) pour pouvoir la compiler.

2.3.2      Installation et configuration

1- Compilation

En supposant que les headers mySQl se trouvent dans le répertoire « /usr/include/mysql », voici la commande à lancer pour compiler la librairie :

gcc -shared lib_mysqludf_udf.c -o lib_mysqludf_udf.so -I /usr/include/mysql

2- Installation

Il faut copier la librairie « lib_mysqludf_udf.so » dans le répertoire de partage de mySQL, appelé aussi dossier des « plugins ». Pour connaitre son emplacement, il suffit de se connecter au serveur SQL et de localiser la variable « plugin_dir » en réponse à la commande « show variables ».

Il faudra ensuite créer une fonction SQL utilisant les fonctions de cette librairie en se connectant au serveur mySQL et en tapant :

USE <MABASE>; ç ATTENTION: la fonction est stockée dans la base de données !

CREATE FUNCTION udf_initid_error RETURNS INTEGER SONAME ‘lib_mysqludf_udf.so’;

La fonction « udf_initd_error(message   varchar(255)) » est alors disponible dans la database mySQL et permet de provoquer des exceptions afin principalement d’interrompre les traitements des triggers en cas d’erreurs logique.

Remarque : Attention, il faut reproduire l’installation / configuration sur tous les nœuds SQL.

3.  Configuration

3.1       Configuration des nœuds SQL

Créer l’arborescence suivante sur chaque nœud SQL :

/data

/data/mysql

/data/mysql/databases

/data/mysql/libs   (<= dossier de sauvegarde de l’UDF mysql définie en 2.3)

/data/mysql/run

Indiquer dans le fichier hosts de la machine les mappages nom/adresse des serveurs de managment (2 dans cet exemple) :

Exemple :

10.20.0.27   sql-mgm-01

10.20.0.28   sql-mgm-02

La configuration d’un nœud SQL consiste à renseigner de façon élémentaire /etc/my.cnf comme pour un serveur mySQL autonome, le nœud va charger grâce à cela sa configuration sur l’un des MGM nodes.

/etc/my.cnf :

[client]

port            = 3306

socket          = /data/mysql/run/mysql.sock

[mysqld]

port            = 3306

socket          = /data/mysql/run/mysql.sock

datadir = /data/mysql/databases

skip-locking

key_buffer_size = 16M

max_allowed_packet = 1M

table_open_cache = 64

sort_buffer_size = 512K

net_buffer_length = 8K

read_buffer_size = 256K

read_rnd_buffer_size = 512K

myisam_sort_buffer_size = 8M

ndbcluster

ndb-connectstring=sql-mgm-01sql-mgm-02

default-storage-engine=ndbcluster

default-table-type=ndbcluster

La commande d’administration sera « rcmysql », voir 4.1.2.

3.2       Configuration des nœuds NDB :

Créer l’arborescence suivante sur chaque nœud NDB :

/data

/data/mysql

/data/mysql/backups  (dossier de stockage des backups des réplicas sur ce nœud, voir 5.2)

/data/mysql/datafiles   (dossier de stockage des données des réplicas sur ce noeud)

/data/mysql/logs (fichiers de logs pour debugging)

/data/mysql/undofiles  (fichiers d’annulation des transactions (rollbacks))

Le fichier /etc/my.cnf contient la définition d’accès aux serveurs de managment pour le nœud NDB :

[mysqld]

port            = 3306

socket          = /var/run/mysql/mysql.sock

datadir = /data/mysql

skip-locking

key_buffer_size = 16M

max_allowed_packet = 1M

table_open_cache = 64

sort_buffer_size = 512K

net_buffer_length = 8K

read_buffer_size = 256K

read_rnd_buffer_size = 512K

myisam_sort_buffer_size = 8M

[MYSQL_CLUSTER]

ndb-connectstring=sql-mgm-01,sql-mgm-02

La commande d’administration sera « rcndbd », voir 4.1.3.

3.3       Configuration des nœuds MGM

Les nœuds MGM propagent la configuration de tous les nœuds du cluster sur l’ensemble des nœuds (SQL et NDB et MGM). Les fichiers de config de ces nœuds sont donc fondamentaux, sont pris en compte lors du démarrage des nœuds MGM. Il est recommandé d’utiliser une configuration de partage globale (SAN, nfs, …) pour que chaque nœud utilise lors de son démarrage et sans ambigüité la configuration n fixée par l’administrateur.

Créer l’arborescence suivante sur chaque nœud MGM :

/data

/data/mysql

/data/mysql/config

/data/mysql/logs

Le démarrage d’un serveur MGM mySQL se fait par la prise en compte d’un fichier de configuration que l’on stoque dans /data/mysql/config/config.ini :

[TCP DEFAULT]

SendBufferMemory=2M

ReceiveBufferMemory=2M

[NDBD DEFAULT]

NoOfReplicas=2

DataMemory=3072M

IndexMemory=3842M

LockPagesInMainMemory=1

[NDB_MGMD]

ID=27

HostName=10.20.0.27

[NDB_MGMD]

ID=28

HostName=10.20.0.28

DataDir=/data/mysql/logs

[NDBD]

ID=29

HostName=10.20.0.29

DataDir=/data/mysql/logs

FileSystemPath=/data/mysql/datafiles

FileSystemPathUndoFiles=/data/mysql/undofiles

BackupDataDir=/data/mysql/backups

[NDBD]

ID=30

HostName=10.20.0.30

DataDir=/data/mysql/logs

FileSystemPath=/data/mysql/datafiles

FileSystemPathUndoFiles=/data/mysql/undofiles

BackupDataDir=/data/mysql/backups

[MYSQLD]

ID=25

HostName=10.20.0.25

[MYSQLD]

ID=26

HostName=10.20.0.26

[MYSQLD]

ID=50

Cette configuration est évidement à adapter en fonction des besoins. Ici nous utilisons deux nœuds SQL, deux nœuds MGM et deux nœuds NDB.

La commande d’administration sera « rcndb_mgmd », voir  4.1.3.

Remarque : Une même et seule version du fichier de configuration « config.ini » doit être présent sur tous les nœuds MGM lors d’un démarrage, pour cela, on peut utiliser la commande :

rcndb_mgmd propage-config

qui propage le fichier config.ini du node MGM sur lequel on est connecté vers tous les autres.

4. Administration

4.1 Options de démarrage des nodes

4.1.1 Noeuds MGM

Ces nœuds sont à démarrer en premier dans le cluster. Sans les nœuds de management démarrés, les autres nœuds (SQL et NDB) risquent de rencontrer des problèmes d’annonce au cluster.

Le lancement et l’arrêt d’un nœud SQL se fait de la même manière que pour un serveur mySQL autonome avec

rcndb_mgmd    start : démarre le nœud

stop : stoppe le nœud, arrête tous les nœuds NDB et tous les nœuds MGM

status : indique l’ensemble des nœuds configurés et annoncés au cluster

init : démarre le nœud à l’indentique de « start » mais écrase la configuration binaire pour prendre en compte le fichier /data/mysql/config/config.ini

Différences sur « init » et « start » :

Lors d’un démarrage du nœud en « init », le fichier de configuration textuel est parsé et est fabriqué un fichier de configuration binaire à ses cotés. Le fichier de configuration binaire permet de prendre des modifications de la configuration du cluster de façon dynamique alors qu’il faut relancer les nœuds dans le cadre d’e la prise en compte de config.ini.

Le démarrage en mode « start » ne prend en compte que le fichier de configuration binaire.

4.1.2      Nœuds SQL

Le lancement et l’arrêt d’un nœud SQL se fait de la même manière que pour un serveur mySQL autonome avec

rcmysql               start : démarre le nœud

stop : stoppe le nœud

4.1.3      Nœuds NDB

Le lancement et l’arrêt d’un nœud NDB se fait par la commande

rcndbd                start : démarre le nœud

stop : stoppe le nœud (ne doit jamais être utilisé, les nodes NDB doivent être arrêtés depuis les nodes MGM, comme indiqué en  4.3.4. Cette option est à utiliser en cas d’urgence seulement, des pertes de données sont possibles alors)

format : DANGER : efface toutes les données du nœud et le démarre (utilisé principalement pour les premiers démarrages et pour certains les recovery)

4.2       Démarrage / Arrêt du Cluster

L’opération d’arrêt / marche du cluster n’est pas anodine et ne doit pas normalement être utilisée, sauf pour des cas extrêmes (maintenance, …), en effet, tous les nœuds vont être stoppés ou lancés, cette opération peut notamment provoquer des pertes de données si elle est effectuée en activité.

L’arrêt et marche du cluster consiste à arrêter / démarrer les nœuds dans un ordre bien précis :

4.2.1      Démarrage :

-          Sur MGM-01

rcndb_mgmd  init

…

Vérifier avec rcndb_mgmd  status (voir 4.3.1)

-          Sur MGM-02

rcndb_mgmd  init

…

Vérifier avec rcndb_mgmd  status (voir 4.3.1)

-          Sur NDB-01

rcndbd   start

…

Vérifier avec ps ax  |  grep ndb que deux process ndbd sont présents

-          Sur NDB-02

rcndbd   start

…

Vérifier avec ps ax  |  grep ndb que deux process ndbd sont présents

-          Sur SQL-01

rcmysql   start

…

-          Sur SQL-02

rcmysql   start

…

Vérifier que tout est OK en se connectant avec un client mySQL sur les frontaux mySQL (password root / mysql) et que, depuis les deux frontaux, on peut accéder aux datas.

4.2.2      Arrêt

-          Sur MGM-01 ou MGM-02

rcndb_mgmd  stop-all

-          Sur SQL-01

rcmysql   stop

…

-          Sur SQL-02

rcmysql   stop

4.2.3      Urgence

En cas d‘urgence seulement, les scripts suivants peuvent aussi êtres utilisés :

-          Arrêt      : rcndb_mgmd stop-cluster

-          Marche : rcndb_mgmd start-cluster (mode init des nodes MGM)

Remarque : L’opération de démarrage de tous les nœuds est rapide, en revanche, la synchronisation inter nœuds ne l’est pas forcément, il ne faudra pas hésiter à attendre plusieurs secondes avant de vérifier l’état du cluster comme indiqué en 4.3.1 et de conclure que cela ne fonctionne pas ou que cela fonctionne.

4.3       Etat du cluster

L’étatdu cluster est consultable depuis un « client » MGM, celui-ci est installé dans nos exemples sur tous les serveurs MGM, il suffit donc, depuis un serveur MGM démarré de taper la commande : ndb_mgm.

Un « shell » de client mgm permet alors de taper divers commandes :

4.3.1      Nœuds connectés et déconnectés

ndb_mgm > show

Connected to Management Server at: localhost:1186

Cluster Configuration

———————

[ndbd(NDB)]     2 node(s)

id=29   @10.20.0.29  (mysql-5.1.41 ndb-7.0.13, Nodegroup: 0, Master)

id=30   @10.20.0.30  (mysql-5.1.41 ndb-7.0.13, Nodegroup: 0)

[ndb_mgmd(MGM)] 2 node(s)

id=27   @10.20.0.27  (mysql-5.1.41 ndb-7.0.13)

id=28   @10.20.0.28  (mysql-5.1.41 ndb-7.0.13)

[mysqld(API)]   3 node(s)

id=25   @10.20.0.25  (mysql-5.1.41 ndb-7.0.13)

id=26   @10.20.0.26  (mysql-5.1.41 ndb-7.0.13)

id=50 (not connected, accepting connect from any host)

Ici nous pouvons observer que 7 nœuds ont été lus dans le fichier de configuration (textuel ou binaire) du serveur de MGM que l’on interroge.

Le nœud n°50 ne s’est pas quant à lui présenté aux serveurs de managment, n’est pas démarré, ou est tombé pour une raison quelconque.

4.3.2      Etat de la mémoire

ndb_mgm > all report memory

Node 29: Data usage is 0%(24 32K pages of total 2560)

Node 29: Index usage is 0%(21 8K pages of total 2336)

Node 30: Data usage is 0%(24 32K pages of total 2560)

Node 30: Index usage is 0%(21 8K pages of total 2336)

Consommation mémoire des différents nœuds. Cette option permet de savoir s’il faut incrémenter les valeurs dataMemory et IndexMemory du fichier de configuration du cluster.

4.3.3      Etat des backups en cours

ndb_mgm> all report BackupStatus

Node 29: Backup not started

Node 30: Backup not started

Lorsque des backups sont en cours d’exécution (voir  5.2), cette commande permet d’observer leur état d’avancement. Ici aucun backup n’est en cours d’exécution.

4.3.4      manipulation des nodes NDB

ndb_mgm> <node_id> STOP

ndb_mgm> <node_id> START

ndb_mgm> <node_id> STATUS

ndb_mgm> ALL STOP

ndb_mgm> ALL START

ndb_mgm> ALL STATUS

5. Sauvegarde et Restauration

5.1 Mode “SINGLE USER”

Le SINGLE USER MODE est utilisé pour restreindre l’accès au cluster à un nœud SQL unique et généralement accessible uniquement par un administrateur et auxquels les applicatifs et/ou les utilisateurs n’ont pas accès, ceci dans le but de faire des opération administratives sans être gêne par les requêtes clientes (restauration, …).

Il faut se connecter sur un nœud MGM et passer la commande :

ndb_mgm –e ‘’ENTER SINGLE USER MODE <ID>’’

(<ID> est le Node-ID d’un nœud SQL administratif (voir fichier de config en  3.3))

Pour revenir à un état normal du cluster, il faut indiquer au serveur de Managment la commande

ndb_mgm –e ‘’EXIT SINGLE USER MODE’’

5.2       Backup base ouverte (« à chaud »)

5.2.1      Introduction

La sauvegarde d’une base sur un cluster mySQL consiste en une opération de sauvegarde des réplicas (données synchronisées inter-nœuds), donc sur chaque nœud NDB, ceci incluant les transactions de base de données en cours (redologs) afin d’assurer l’intégrité des données en cas de restauration.

Une sauvegarde consiste en la création d’un jeu de données sur chaque nœud de stockage NDB. Nous choissons de les stocker  dans les dossiers /data/mysql/backups/

La restauration sera une restauration des backups ainsi réalisés sur chaque nœud (un backup d’une database sur n nœuds NDB se restaurera avec une n opérations de restaurations)

5.2.2      Méthode

Pour lancer un backup d’une database, il faut se positionner sur un nœud MGM et utiliser la commande :

rcndb_mgmd backup

Ceci aura pour effet de demander la création d’un backup des métadatas des databases pour chaque nœud NDB et de ranger les « fragments » de backup, su chaque nœuds, dans le répertoire /data/mysql/backups/BACKUP/BACKUP-<Q><HHMMSS>/ où Q est le quantième de la date de déclanchement du backup et HHMMSS l’heure de ce même déclanchement.

Le dossier de backup ainsi créé sur chaque nœud NDB contient :

-          *.ctl <= Les fichiers de contrôles

-          *.Data <= Les fichiers de données

-          *.log <= Les fichiers de transactions pour le recovery des datas après restauration/

5.3       Restauration

5.3.1      Introduction

Comme indiqué en introduction du paragraphe de backup, la restauration d’une database consiste en la restauration de n sauvegardes présentes sur les n nœuds NDB.

5.3.2      Méthode

5.3.2.1         Quelle restauration faut-il effectuer ?

En fonction du type de perte de données et de la volonté de restaurer tout ou partie du cluster ou d ‘une base de données, les « checklist » ne sont pas exactement les mêmes.

Il se distingue globalement trois besoins en matière de restauration de données depuis une sauvegarde :

-          CLUSTER (tout est foutu => restauration générale)

-          DATABASE (une base de données est HS [ drop database, erreur FS, …], il faut la restaurer

-          TABLE [ erreur logique et demande utilisateur ]

Trois besoins, trois méthodes. Au-delà de cela, il faudra réfléchir avant d’agir !

a.        Restauration du CLUSTER :  Restauration de la totalité du cluster

• Positionner le cluster en « SINGLE USER MODE » (voir  5.1)
• Arrêter le cluster (voir  4.2.2)
• Démarrer tous les nœuds NDB en initialisant des espaces de données
  • Sur chaque nœud NDB : rcndbd  format
• Restaurer les métadatas (create table, …)
  • Sur un des nœuds NDB :

ndb_restore   –c   <ip MGM> \

–n  <ID NDB>  –m –b  <ID backup>   \

–backup_path=/data/mysql/backup/

• Restaurer les datas
  • Sur tous les nœuds NDB :

ndb_restore   –c   <ip MGM> \

–n  <ID NDB>  –r –b  <ID backup>   \

–backup_path=/data/mysql/backup/

• Restaurer les objets de base de données (triggers, procédures stockées, …)
  • Sur tous les nœuds SQL :
    • rcmysql  start
    • Repérer le dernier dump sql structuel dans le dossier /data/mysql/backup/  et de type « dump_STRUCT_<yyyyy>.sql » puis l’appliquer au serveur  avec :

mysql  –uroot  <  /data/mysql/backup/dump_STRUCT_<yyyyy>.sql

• Sortir le cluster du « SINGLE USER MODE »

b.       Restauration d’une base de données : Restauration partielle d’une database ‘DB’

• Positionner le cluster en « SINGLE USER MODE »
• Détruire la database ‘DB’ :
  • Sur chaque nœud SQL :
    • mysql  –uroot  -pmysql
    • mysql>  drop database  db ;
    • mysql>  exit ;
• Restaurer les métadatas de la database (create table, …)
  • Sur un des nœuds NDB :

ndb_restore   –c   <ip MGM> \

–n  <ID NDB>  –m –b  <ID backup>   \

–backup_path=/data/mysql/backup/ \

–include-databases=db

• Restaurer les datas
  • Sur tous les nœuds NDB :

ndb_restore   –c   <ip MGM> \

–n  <ID NDB>  –r –b  <ID backup>   \

–backup_path=/data/mysql/backup/ \

–include-databases=db

• Restaurer les objets de base de données (triggers, procédures stockées, …)
  • Sur tous les nœuds SQL :
    • rcmysql  start
    • Repérer le dernier dump sql structuel de la database ‘db’ dans le dossier /data/mysql/backup/  et de type « dump_STRUCT_ DATABASE_DB_<yyyyy>.sql » puis l’appliquer au serveur  avec :

mysql  –uroot  <  /data/mysql/backup/dump_STRUCT_DATABASE_DB_<yyyyy>.sql

• Sortir le cluster du « SINGLE USER MODE »

c.        Restauration d’une table : Restauration d’une table ‘T’ de la database ‘DB’

• Positionner le cluster en « SINGLE USER MODE »
• Détruire la table ‘T’ de la database ‘DB’ :
  • Sur chaque nœud SQL :
    • mysql  –uroot  -pmysql
    • mysql>  drop table  db.t ;
    • mysql>  exit ;
• Restaurer les métadatas de la database (create table, …)
  • Sur un des nœuds NDB :

ndb_restore   –c   <ip MGM> \

–n  <ID NDB>  –m –b  <ID backup>   \

–backup_path=/data/mysql/backup/ \

–include-databases=db \

–include-tables=t

• Restaurer les datas
  • Sur tous les nœuds NDB :

ndb_restore   –c   <ip MGM> \

–n  <ID NDB>  –r –b  <ID backup>   \

–backup_path=/data/mysql/backup/ \

–include-databases=db \

–include-tables=t

• Sortir le cluster du « SINGLE USER MODE »

5.3.2.2         Syntaxe générale de « ndb_restore »

ATTENTION : Cette commande est à exécuter DEPUIS un nœud de stockage NDB.

ndb_restore

–connect <ip addr> (ou ‘–c’)                    <= MGM serveur qui pilote la restauration

–restore_meta (ou ‘- m’)                          <= restaurer les métadatas (DDL)

–nodeid=<node ID> (ou ‘-n’)                   <= le numéro d’un nœud NDB

–backupid=< backup ID> (ou ‘-b’)          <= le numéro du backup (voir 5.2.2)

–rebuild-indexes (ou ‘- r’)                         <= reconstruction des index

–backup_path=/data/mysql/backup    <= le chemin des backups sur les nœuds NDB

[ --include-databases=ma_database ]                 <= restreindre le backup à cette database

[ --include-tables=table1,table2 ]          <= restreindre le backup à ces tables

[ -- print_log ]

6. Considérations pour les développeurs

6.1 Limitations classiques du cluster NDB

Il existe de nombreuses limitations quant à l’utilisation d’un cluster au sens de mySQL, mais la plupart de celles-ci sont exotiques et peuvent être de ce fait contournées facilement.

Les limitations « classiques » sont :

-          Limitation de 128 champs par table

-          Interdiction d’utiliser des clés étrangères

-          Interdiction d’utiliser la création de tables temporaires (temporary tables)

-          Pas d’index sur les champs FULLTEXT ou LOB (BLOB, CLOB, …)

-          Obligation de créer sur tous les nœuds SQL les déclencheurs, fonctions et procédures stockées (métadatas)

-          Interdiction d’utiliser les transactions en SavePoint (plusieurs rollbacks possibles en différents points sur une seule transactions ouverte)

6.2       Problématique liée à l’absence de clés étrangères

L’absence de possibilité d’utiliser les clés étrangères pour une table gérée par le moteur NDBENGINE empêche par définition de s’assurer de l’intégrité référentielle ou de la mise à jour en cascade des données.

Pour pallier à ce manque, il convient d’utiliser des TRIGGERs, principalement AVANT  opération DML dans le but d’effectuer manuellement les vérifications d’intégrité référentielle et de provoquer une erreur (voire les fonctions UDF en  2.3) en cas d’anomalie détectée.

ATTENTION : les triggers (comme les fonctions et procédures stockées) ne sont pas des objets dépendants des tables mais de la base de données. Ils ne sont donc pas gérés par les nœuds NDB mais par les nœuds SQL. Aucune propagation de configuration d’un nœud SQL sur un autre n’existe dans cette version du cluster (7.x), il faut donc, sur tous les nœuds SQL, définir les mêmes objets.

6.2.1      Des TRIGGERS pour assurer l’intégrité référentielle

Prenons l’exemple une table TABLEFILLE(IDFILLE, NOM, IDPARENT) qui devrait être liée à une table « mère » TABLEPARENT(IDPARENT, NOM) par le champ IDPARENT.

L’absence de clé étrangère sur ces tables ne permet pas d’assurer l’intégrité référentielle, nous allons utiliser un trigger pour pallier à ce manque.

Voici le trigger permettant de respecter l’intégrité référentielle qu’il faut créer sur tous les nœuds SQL :

DROP TRIGGER IF EXISTS TG_TABLEFILLE_PARENTKEYOK_BI;

DELIMITER |

CREATE TRIGGER TG_TABLEFILLE_PARENTKEYOK_BI BEFORE INSERT ON TABLEFILLE

FOR EACH ROW BEGIN

DECLARE RESULTAT INT;

IF ((SELECT COUNT(*) FROM TABLEPARENT WHERE TABLEPARENT.IDPARENT=new.IDPARENT)=0) THEN

SET RESULTAT=udf_initid_error(“Intégrité référentielle violée sur TABLEFILLE –> TABLEPARENT”);

END IF;

END;

|

DELIMITER ;

6.2.2      Des TRIGGERS pour assurer les mises à jour en cascade

L’absence de clé étrangère sur ces tables ne permet pas d’assurer la mise à jour en cascade des lignes de tables filles lorsque des lignes dépendantes sur une table mère sont supprimées.  Nous allons encore une fois utiliser un trigger pour pallier à ce manque.

Reprenons l’exemple des tables TABLEFILLE et TABLEPARENT de 6.2.1.

DROP TRIGGER IF EXISTS TG_TABLEPARENT_DELCASCADE_BD;

DELIMITER |

CREATE TRIGGER TG_TABLEPARENT_DELCASCADE_BD BEFORE DELETE ON TABLEPARENT

FOR EACH ROW BEGIN

DELETE FROM TABLEFILLE WHERE TABLEFILLE.IDPARENT=old.IDPARENT ;

END;

|

DELIMITER ;

6.3       Codes d’erreurs rencontrés

CopyLeft:

Ces données sont issues d’un document interne de production provenant d’un DataCenter français.

Comme une vue au sens classique d’Oracle, une vue matérialisée (“MaterializedView” ou “MV”) est une vue basée sur une requête SQL. A l’instar d’une vue classique, lorsque l’on crée une vue matérialisée, Oracle crée alors une table dont la structure correspond exactement à celle induite par le résultat du select associé. Les données de la vue matérialisée sont alors issues de la requête SQL et recopiées physiquement dans cette table, on dit alors que les données sont “matérialisées”.

1 – Introduction / Rappels :

Les avantages d’une vue matérialisée sont globalement dans la rapidité d’accès aux données, en effet, si les tables dont sont issues les requêtes SQL induisant les vues matérialisées sont complexes, le fait d’y accéder par l’intermédiaire d’une vue matérialisée en rendra l’accès extrêmement plus rapide puisque celle-ci sont en fait recopiées physiquement dans la table de la dite vue et de nécessite plus l’interprétation d’un plan d’exécution complexe pour les récupérer.

Les vues matérialisées sont globalement utilisées pour accélérer l’accès à des données dont le quotient de mise à jour demeure faible. En effet, si les données d’une MV sont matérialisées dans une table, il peut exister à un instant <T> un décalage entre les données réellement présentes dans les tables pointées par la requête SQL et les données physiquement recopiées, une mise à jour de ces données physique est alors nécessaire pour se rapprocher des données réelles.

Dans ce contexte, nous verrons qu’il existe plusieurs méthodes pour mettre à jour une vue matérialisées, plus ou moins adaptées à l’utilisation que les utilisateurs en font et permettant aussi de faire au sens d’Oracle de la réplicationde données entre hôtes distants.

2 – Création/Suppression d’une Vue Matérialisée :

La création d’une vue matérialisée se fait par l’instruction :

create materialized view <nom_vue_materialisée> as <requête_SQL>
                    [ refresh <mode> [ <type> ] [ with <cycle> ]
                      [ FORCE | FAST ] ]

Exemple:

SQL> create materialized view mv_personnes

2 as select c.nom, c.prenom, v.nomville from clients c,
ville v where c.id_ville=v.id_ville;

SQL> select * from mv_personnes;

NOM      PRENOM      NOMVILLE

------   -------     -------------------------------
NOM_1    PRENOM_1    ANGOULEME
NOM_2    PRENOM_2    BASTIA

Une vue matérialisée se détruit par un drop au sens classique du terme :

SQL> drop materialized view mv_personnes;

Note: Les vues systèmes USER_MVIEWS et DBA_MVIEWS permettent aux utilisateurs et aux DBAs d’obtenir toutes les informations sur les vues matérialisées auxquels ils ont accès. Le champ “query” permet notament d’indentifier la requête SQL induisant la vue matérialisée et “mview_name” le nom de la table physique créée pour matérialiser les données de cette requête.

3 – Modes de rafraichissement des vues matérialisées :

Comme nous l’avons évoqué précédement, la pertinence d’une vue matérialisée est caractérisée par la fréquence de mise à jour (ou de synchronisation) de ses données par rapport aux données des tables mères sur laquelle porte la requête SQL qui l’induit. En clair : quelle est la méthode et la fréquence de rafraichissement des données matérialisées de la vue par rapport aux données réélles existant dans les tables pointées par la requête SQL de la vue matérialisée?

3.1) Rafraichissement synchrone sur validation

Le mode de rafraichissement sur validation des vues matérialisation est celui qui vous permet d’assurer une équivalence parfaite entre les données matérialisées et celles dynamiques issues de la requête SQL caractéristique. Chaque validation transactionelle (commit) aura pour effet de rafraichir les données de la MV, une donnée validée dans une table mère impliquera au préalable une donnée inscrite dans la table de la MV.

L’équivalence des données de la MV est donc assurée de manière synchrone par rapport aux données situées dans les tables pointées par la requête SQL caractérisant la vue.

C’est la plus éfficace des mises à jour en terme fonctionel, c’est la moins efficace en CPU et consomation mémoire. Une telle façon de fonctionner est éfficace si la MV se fait sur la même database contenant les tables mères pointées par la requête SQL. Si la MV est distante, des problèmes de performance apparaissent très vite et cette méthode est déconseillée.

En clair, cette méthode vous permet d’améliorer des requêtes lourdes sur une instance de base de données.

Syntaxe :

 create ... refresh on commit;

3.2) Rafraichissement asynchrone sur demande

Une MV en mode de rafraichissement sur demande, comme son nom l’indique, possède des données matérialisées qui sont mises à jour de façon evènementielle sur demande (administrative, par automatisme PLSQL, …). La méthode de rafraichissement est donnée par le package DBMS_REFRESH et la procédure REFRESH(‘<nom_MV>’),

Syntaxe :

 create materialized view MV1 ...;
 ...
 execute DBMS_REFRESH.REFRESH('MV1');

Note: Dans le cadre d’une réplication de tables, le package DBMS_REFRESH possède la méthode REFRESH_ALL_MVIEWS qui permet de rafraichir toutes les MV sans les nommer une à une.

3.3) Rafraichissement asynchrone différentiel cyclique

Ce mode de rafraichissement est bien plus souvent utilisé que ces prédécesseurs car il économise les ressources de la base de donénes maître en réduisant le nombre de mises à jour nécessaires entre les MVs et les tables maitresses.

Le commutateur “start with” va permettre de définir une fréquence de mise à jour des données en collaboration avec le commutateur “next” qui permettra de définir l’intervalle de future mise à jour après la première éffectuée.

Syntaxe:

create materialized view MV1
refresh
start with trunc(sysdate+1)+ 8/24
next trunc(sysdate + 1) + 24/24
as select * from t1, t2;

Dans cet exemple, MV1 verra ses données matérialisées créées à 8 heures puis rafraichies automatiquement tous les jours à minuit.

4 – Type de rafraichissement FORCE ou FAST :

4.1 – Introduction :

Il existe deux “types” de rafraichissement des données matérialisées, le type FORCE ou le type FAST.

Le mode FORCE est le mode par défaut et implique le comportement de tous les exemples décrits dans les paragraphes précédents, il est donc inutile d’en reparler ici.

Le mode FAST implique une notion de mise à jour RAPIDE en opposition à une mise à jour plus lente qu’est la mise à jour complète des données d’une MV. Vous l’aurez compris (ou intuité), nous parlons ici d’une mise à jour différentielle des données matérialisées.

4.2 – Type de mise à jour Rapide des données matérialisées :

Le typde mise à jour “rapide” d’une MV est un type incrémental. Afin de minimiser le temps de comparaison des données présentes dans les tables mères par rapport aux données présentes dans les tables des MV, un fichier de journalisation des données modifiées est créé à cet effet, ou plustot une “table” de journalisation des données matérialisées : on parle de MATERIALIZED VIEW LOG (tables “MLOG$_*”).

Ces tables de log “MLOG$_*” comprennent les modifications éffectuées sur les tables mères d’une MV (insert, update, delete) et permettent au MV de ne synchroniser que les enregistrements ayant subits des modifications, au contraire du type FORCE qui concerne l’ensemble des données de la MV (et donc des tables mères).

Ce type de fonctionnalité est donc précédé de la création de ces tables de LOG grâce à la commande :

SQL> create materialized view log on T;

Ceci ayant pour effet de créer une table MLOG$_T sur le host courant, une table qui contiendra à dater de cet nstant toutes les modifications des lignes de la table T. Il conviendra par la suite de créer une vue matérialisée sur T pour bénéficier de ce journal.

La problématique de la fréquence des mises à jour ne chande pas (sur demande, on commit, …) sauf que celle ci se fera à dater de ce moment de manière différentielle et non plus de manière complète, ce qui représentera un gain de temps fondamental.

Il convient ensuite de préciser que l’on souhaite une vue matérialisée dont le typde mise à jour est basé sur l’exploitation de ces tables de log Oracle pour éffectuer des mises à jours incrémentales selon une fréquence à définir:

SQL> create materialized view MV REFRESH FAST on select * from T;

La fréquence de lecture des journaux (tables) de log seront induites par les sous commutateurs start et nextpermettant de définir une condition initiale pour débuter une mise à jour et une récurence.

5 – Réplication de données :

5.1 – Introduction :

La réplication de données selon Oracle est assurée par la mise à jour de données de tables par les méthodes de synchronisations de données éffectuées grâce au concept de vue matérialisée.

Une réplication de données se fera donc à l’aide de l’utilisation des vues matérialisées, des notions qui seront accessibles à distance à l’aide de la notion de DB-LINK (Database Link) / liaison inter-bases de données.

Le principe d’un DB-LINK est d’accéder de manière transparente à des tables situées en dehors de l’instance de base de données principale, généralement située sur un autre hote accessible en TCP/IP. Un DB-LINK Oracle permet donc de lier des schémas de base de données inter instances entre elles.

La création d’un DB-LINK se réalise par la syntaxe suivante :

CREATE PUBLIC DATABASE LINK CONNECT TO <user> IDENTIFIED BY <pwd> USING '<tsn_conn>' ;

Avec les paramètres suivants :

- <user> : nom d’utilistateur de la DB distante

- <pwd>: le password de <user>

- <tsn_conn> :  la définition d’accès à la database distance par le TNS_NAME local.

Imaginons maintenant, à travers la définition de DB-LINK, qu’une table distante soit accessible depuis une instance de base de données locale, si nous créons sur la table distante un journal de log, rien ne nous empêche sur la base locale de créer alors une vue matérialisée en mode FAST, vue induuite par une requête utilisant cette même table distante caractérisée par un journal de log. Nous venons à cet instant précis d’alimenter une table d’une instance I1 par une table d’une instance I2, le tout, quel que soit la distantce, sur un réseau TCP/IP : Autrement dit : nous venons de faire de la réplication de données.

5.2 – Mise en place :

Un petit peu pressé par le temps, je publie cet article maintenant en l’absence de rédaction de ce paragraphe. Sous peu, vous aurez sous le 5.2) l’exacte syntaxe pour mettre en place concrètement et rapidement la réplication de données selon Oracle (i.e. à travers des MV en type FAST).

En attendant, certaines informations vous seront peut être utiles, d’où la publication rapide !

Cette procédure d’installation est validée sur les distributions 9iR2, 10g et 11g, vous pouvez trouver les éléments à télécharger directement en libre accès sur le site d’Oracle. Notez que Oracle n’éxige pas de lisence d’installation et, même si l’installeur vous averti que vous êtes hors lisence, le produit fonctionnera tout de même, ce qui vous permet de l’évaluer rapidement, et ceci pour toutes ses fonctionalités.

1- Architechture OFA

Oracle recommande aux administrateurs systèmes d’installer leur produits selon une définition particulière des filesystem nommée Oracle Flexible Architecture (OFA), mais ceci n’est que recommandation, libre à vous de procéder différemment.

Vous devez, à minima, créer un répertoire u01 à la racine de votre disque pour identifier un utilisateur n°1 d’une gamme de produit Oracle sur votre serveur. Le répertoire utilisateur Oracle contiendra à minima les sous répertoires app/products dans lequel sera déployé les différents produits d’Oracle (10g, 11g, …)

Deux variables d’environnement Oracle sont alors nécessaires car seront utilisées par les moteurs ainsi que par les instances des bases de données :

Exemples:

export ORACLE_BASE = /u01/app/oracle

export ORACLE_HOME = $ORACLE_BASE/10.2/db_1

Le module d’installation du moteur de bases de données Oracle OUI (Oracle Universal Installer) a besoin de l’existence de ces répertoires et de la déclarations de ces variables d’environnement pour fonctionner, le reste de l’arborescence OFA sera automatiquement généré.

2 -  Groupes Oracle et utilisateur

Oracle a besoin à minima de deux groupes systèmes dont les noms vous seront demandés à l’installation, il faut donc au préalablement les créer :

oinstall: groupe nécessaire à OUI

dba: les utilisateurs OS de ce groupes seront automatiquement considérés comme utilisateurs DBA par Oracle

oper: les utilisateurs OS de ce groupes seront automatiquement considérés comme utilisateurs OPERATEURS par Oracle

Vous devrez égallement créer un utilisateur “oracle” que vous associerez à chaque de ces trois groupes car, celui – ci pourra ainsi procéder à l’installation du logiciel puis, sera considéré par Oracle comme DBA et pourra poursuivre sur la création d’une première database.

Nous verrons dans d’autres articles l’intérêt de l’appartenance d’un user OS à ces groupes pour la manipulation des databases Oracle.

3 – Installation

Connectez vous avec l’utilisateur “oracle” et ouvrez (si ce n’est pas déjà fait), une session graphique. Le script de lancement de l’OUI se nomme runInstaller.sh, lancez-le et suivez pas à pas la procédure, elle est très simple.

Remarque: Si vous ne possédez pas de distribution “qualifiée” par Oracle, il vous faudra ajouter le commutateur “–ignoresysprereqs” au script pour acquiescer le fait que vous prenez un risque et que vous ne pouvez pas dans ce cas bénéficier du support Oracle.

Même si cette installation doit se faire sous l’autorité du user oracle, il vous faudra à la fin exécuter des scripts en tant que root. Le chemin de ces scripts vous sera indiqué par l’OUI et ne demandent aucun paramètre, ils configureront votre produit pour les options de licence que vous aurez spécifié au début de l’installation.

Une fois le moteur de base de données Oracle installé, OUI permet, si vous le souhaitez, de lancer automatiquement d’autres assistants de configuration réseau (“netca”) et de configuration de databases (“dbca”), mais ces deux modules font partie d’un article supplémentaire sur ce site.

Note: N’oubliez pas d’aller modifier le fichier /etc/profile.d/oracle.sh pour aller y insérer les bonnes valeurs des variables d’environnement Oracle car c’est ici qu’elles seront initialisées par les scripts de démarrage de init.d.