Sommaire

Dec 26, 2015 - Architecture Orientée Message, Spécification

Architecture de services Orientée Messages, Spécification

Introduction

Ce document a pour vocation de décrire une architecture de principe avec les besoins associés.

Cette architecture répond à un besoin de remise de courrier : permettre la distribution de messages de producteurs vers un ou plusieurs consommateurs.

Expression des besoins

Story Application

En tant qu’ administrateur système ayant :

  • des lots de traitements à faire réaliser par un programme sur plusieurs machines pour améliorer les performances (répartition de charge)
  • des machines devant être non-connectée régulièrement
  • des tâches dont la durée de traitement est plus grande que 10 s

J’aimerais :

  • faciliter la supervision des tâches (restantes à exécuter, en cours, …)
  • ne pas perdre une tâche non finie en cas de crash du worker + redistribution automatique sur un autre worker
  • pouvoir ajouter/supprimer des workers facilement, même s’ils sont sur plusieurs machines. Les tâches sont équitablement réparties entre les workers.
  • pouvoir mettre en oeuvre / déployer la solution sur plusieurs architectures et systèmes d’exploitation dont : x86, x86_64, ARM avec GNU/Linux, Windows, Mac OS X

La solution actuelle utilise différents composants :

  • des fichiers sur disque contenant les tâches à exécuter + des scripts lancés à la main pour consommer ces fichiers
  • des commandes transférées en UUCP. Les workers (machines qui exécutent les commandes) récupèrent le travail avec cron

Story Logs

En tant qu’ administrateur système ayant :

  • en gestions plusieurs services (web , mail, dns, base de données, …) produisant des traces d’activité (log),
  • plusieurs sources (assimilées à des clients) produisant des logs

J’aimerais :

  • centraliser les flux de logs
  • pouvoir orienter les flux vers différentes destination (poubelle, archivage, notification d’erreur, …) selon des marquages sur les messages (clef de routage)

Story Business

En tant que représentant du métier X, j’aimerais :

  • avoir une configuration simple sur service de messagerie (=1 en entrée, 1 en sortie de l’application)
  • ne pas m’occuper de la configuration du serveur de messagerie
  • avoir des garanties de remise de messages
  • avoir un suivi (graphe) des volumétries de messages
  • pouvoir tester deux (minimum) implémentations d’une application sur le même flux de message (1 en production et 1 en test)
  • pouvoir publier/consommer ~5 k message par seconde
  • pouvoir supprimer toutes les tâches en attentes d’une application

Architecture

L’architecture proposée est une architecture 3-tiers. Les parties sont :

  1. les applications qui produisent des messages
  2. le service de routage des messages
  3. les applications qui récupèrent des messages

schéma de principe

Notes :

  • si une application a besoin de récupérer les résultats en sortie du routage des messages, celle-ci doit établir une seconde connexion au service en tant que consommateur.
    • exemple 1 : une application qui transforme le format d’un message délimité par des virgules vers un format json
    • exemple 2 : une application qui réduit la taille d’une image pour générer des vignettes

Licence

logo creative common by-sa 3.0 Creative Commons Paternité – Partage à l’Identique 3.0 non transcrit

Dec 20, 2015 - RabbitMQ et la répartition de tâche facile

Note sur l’équilibrage de charge de calcul sur plusieurs machines

Préparation du broker

Les commandes fournie par la suite amqp-tool sont utiles mais la version packagée dans homebrew (gestionnaire de paquet pour Mac OS X) n’ont pas la capacité de déclarer la configuration du serveur. Il faut donc réaliser la configuration sur le serveur avant de continuer.

Il faut pour cela déclarer un point d’échange. Dans le cas d’exemple, ce sera dns_ex.

Afin de pouvoir conserver les tâches même si aucun exécuteur n’est lancé nous ajoutons manuellement une file de message. Ajoutons la queue q_dns_ttl avec une expiration automatique des messages à 1 jour (= 24 * 60 * 60 * 1000 = 86400000 ms).

Afin de recevoir des tâches dans la file d’attente, il faut associer la file avec le point d’échange.

On accepte tous les messages entrant dans le point d’échange (routing key = “#”).

Publication des tâches

Préparation des données à fournir à notre tâche

Pour l’exemple, utilisons la liste des sites les plus populaires fournie par Alexa.

script issu de gist.github.com

wget -q http://s3.amazonaws.com/alexa-static/top-1m.csv.zip
unzip top-1m.csv.zip
awk -F ',' '{print $2}' top-1m.csv|head -1000 > top-1000.txt
rm top-1m.csv*

Le script bash qui constitue la tâche

Contenu du fichier dig.sh :

read line
echo "Message: $line"
dig $line

On le rend exécutable :

chmod +x dig.sh

Exécution des tâches

Envois des tâches

Explication rapide des options :

  • “-e” : exchange name : le nom du point d’échange
  • ”–url” : l’URL de connexion au serveur.
  • “-l” : pour prendre chaque line en entrée comme un message séparé
cat top-1000.txt  | amqp-publish -e "dns_ex" --url=amqp://guest:guest@localhost:5672 -l

Réception et exécution

Explication rapide des options :

  • “-q” : queue name : le nom de la file d’attente
  • “-p” : prefech : le nombre de message à prendre dans la file. Permet d’aumenter les performances si la tâche est rapide par rapport au temps de transfert du message.
amqp-consume -q "q_dns_ttl" --url=amqp://guest:guest@localhost:5672 -p 1 ~/dig.sh

Liens

Licence

logo creative common by-sa 3.0 Creative Commons Paternité – Partage à l’Identique 3.0 non transcrit

Dec 19, 2015 - Compression avec 7z

Aide mémoire sur les paramètres de 7z

L’outil 7z est un outil de compression :

  • libre
  • gratuit
  • multiplateforme (windows, gnu/linux, mac et probablement d’autres)
  • doté d’une interface graphique (clic-bouton)
  • doté d’une interface console (scripts)

Archivage par interface graphique

  • format de fichier : 7z
  • algorithme : LZMA2
  • niveau de compression : ultra
  • nombre de threads : autant que de coeurs processeurs réels

Archivage en console

7z a -t7z -m0=lzma2 -mx=9 -ms=on <output file>.7z <input files>

Découpage automatique en plusieurs fichiers

7zip est capable de répartir le contenu compressé sur plusieurs fichiers.

L’option -v est utilisée pour cela.

Exemple de découpage tous les 1 Go.

7z a -t7z -v1g -m0=lzma2 -mx=9 -ms=on <output file>.7z <input files>

Licence

logo creative common by-sa 3.0 Creative Commons Paternité – Partage à l’Identique 3.0 non transcrit

Nov 18, 2015 - Plan de Continuité d'Activité

Méthodologie : votre plan de continuité d’activité pas-à-pas

Préambule

L’article original est disponilble sur qualys.fr. Il est recopié ici afin de pouvoir y accéder suite à un changement d’URL.

Le guide est disponible en PDF sur le site original ou en PDF en copie sur ce site.

Introduction

Auteur de l’article Jerome Saiz le 27 février 2014 - 16:20,

mots clefs : incident, plan de continuité d’activité, plan de reprise d’activité

Mettre en oeuvre un Plan de Continuité d’Activité est loin d’être une formalité : analyses des risques, connaissance précise des exigences métiers, cartographie des processus de l’entreprise, coordination avec les RH… Le PCA peut faire peur ! Il s’agit pourtant d’un volet essentiel à la stratégie sécurité de l’entreprise, améliorant considérablement sa résilience.

Si vous faites partie de ces RSSI fraîchement promus à qui incombe la mise en oeuvre d’un PCA, réjouissez-vous : depuis l’an dernier le SGDSN (Secrétariat général de la défense et de la sécurité nationale) édite un guide gratuit permettant de mener un projet PCA de A à Z. Des conseils pratiques aux étapes indispensables en passant par les fiches-outils, tout est là. C’est un travail remarquable de clarté.

La méthode

La méthode présentée s’articule en dix objectifs répartis sur cinq étapes. Le guide déroule le tout en 27 fiches pratiques organisées selon un code couleur en fonction des cinq étapes méthodologiques présentées ci-dessous. Il offre également des modèles de fiches pour l’auto-évaluation des bonnes pratiques, une fiche-modèle d’analyse et d’évaluation des risques et une fiche de RETEX.

Les dix points de la méthodologie présentée dans le guide sont les suivants :

Définir le contexte et les objectifs

Evidemment, avant de se lancer il faut décider de ce que l’on souhaite garantir ! Il faudra, par exemple, identifier les activités essentielles à l’entreprise non pas uniquement pour continuer à opérer mais également pour continuer à respecter ses éventuelles obligations réglementaires. A l’issue de cette analyse l’entreprise devrait disposer d’une liste de ressources critiques indispensables à son fonctionnement (activité, processus, flux…)

Identifier et formaliser les besoins de continuité

Ici l’entreprise décide, pour chaque ressource critique identifiée à l’étape précédente, du niveau de service minimum requis (potentiellement en mode dégradé) et de la durée d’indisponibilité maximale acceptable.

Evidemment chaque ressource critique exige à son tour d’autres ressources pour fonctionner (humaines, infrastructures, SI, externes – matières premières et prestations). Elles seront elles aussi identifiées et définies à cette étape.

A l’issue de cet inventaire l’entreprise peut déjà chiffrer l’impact d’une interruption de l’activité. L’équipe en charge de la préparation du PCA soumet alors à la Direction pour validation l’inventaire des ressources critiques et les impacts potentiels de leur indisponibilité sur l’activité.

Identifier et gérer les risques prioritaires

Il s’agit ici d’une démarche classique d’analyse des risques visant à évaluer et traiter les risques auxquels est exposée l’entreprise en fonction de ses enjeux (« activités stratégiques, chaine de valeur, conjoncture, opportunités, concurrence, capacité financière… » précise le guide). A titre d’exemple la méthode couvre cette section sur trois fiches très didactiques qui expliquent la notion de risque et proposent une méthode basée sur les classiques matrices d’évaluation.

Choisir les scénarios à prendre en compte

En s’appuyant sur le travail d’inventaire des risques réalisé à l’étape précédente, il faut maintenant choisir les scénarios de risques résiduels à couvrir (les autres auront été traités précédemment). L’on cherche à couvrir ici les scénarios conduisant à « un niveau d’activité ou une durée d’interruption inacceptable » , dixit le guide.

Formaliser les moyens et les procédures

C’est ici que l’on entre dans le concret : il s’agit de créer ou de sourcer les moyens redondants qui devront être disponibles à l’activation du PCA. Il peut s’agir de palettes de postes de travail mis de côté, de la construction d’une salle informatique de secours, mais aussi de la recherche de partenaires ou de prestataires capables d’intervenir durant la crise (fourniture de matériel, de puissance de calcul, de réseau, de communication, de positions de travail, etc…).

Evidemment les ressources seules ne servent à rien et il faudra les accompagner des procédures nécessaires afin de savoir exactement comment les mettre en oeuvre le jour venu.

Il s’agit là d’une étape cruciale et, sans surprise, laborieuse !

Définir la stratégie de continuité

Cette étape est l’arbitrage financier issu des deux précédentes. L’on n’est plus ici dans la décision ( « on couvre / on ne couvre pas » ), mais plutôt dans l’optimisation.

Sachant que le coût des moyens décidés à l’étape précédente sera proportionnel aux exigences en matière de délai de reprise ou de niveau d’activité, il est possible d’optimiser au mieux les moyens déployés en s’appuyant sur les scénarios de sinistre et leurs impacts. Après tout l’objectif est de maintenir l’activité à minima le temps de revenir à un état nominal. Et non de se remettre sur pieds immédiatement et totalement (ce qui serait ruineux et rarement nécessaire)

Spécifier les procédures de gestion de crise et de communication

Ce point de la méthode est un projet à lui seul ! Mais la gestion de crise est une composante essentielle dans le cadre du PCA qu’il est impossible d’ignorer. Le guide détaille les fonctions minimales nécessaires à une cellule de crise intégrée au plan (veille, procédures d’escalade et aide à la décision par l’analyse des différents scénarios durant la crise)

Rédiger le plan de continuité et la documentation associée

Il s’agit désormais de rédiger « la bible » du PCA. Le document produit ici va d’abord décrire la démarche logique ayant conduit aux choix stratégiques qui ont été faits, ainsi que les scénarios retenus. Puis il décrira par le détail les ressources concernées, les moyens et les procédures mis en oeuvre lors du déclenchement du plan, ainsi que les responsables concernés et les actions attendues d’eux.

Ce document doit être facilement accessible en cas de besoin (dans la panique…), simple à comprendre même pour des collaborateurs fraîchement recrutés (ou en panique…) et capable d’être mis à jour lorsque les ressources de l’entreprise évoluent.

Assurer la capacité de mise en oeuvre du plan

Avoir un plan, c’est bien, être certain qu’il pourra être mis en oeuvre c’est mieux ! Il s’agit ici pour les responsables en charge des moyens de s’assurer que ces derniers sont disponibles, et que les procédures de déploiement existent et sont comprises par les personnels concernés.

Faire évoluer le plan : exercices et retours d’expérience

Un PCA doit être testé régulièrement et chaque test doit être documenté et solidement debriefé : les oublis, les manques, les procédures mal comprises… tout doit être consigné afin de pouvoir améliorer le plan (le guide propose d’ailleurs à cet effet une fiche-type pour les RETEX).

Et bien entendu l’entreprise évolue, ses systèmes changent, ses activités aussi et il est donc nécessaire de contrôler régulièrement l’adéquation du PCA à la réalité de l’entreprise.

Licence

L’article est issu de https://magazine.qualys.fr/conformite-organisation/methodologie-continuite-activite-pca/.