Juin 19

Domotique, le choix d’une vulgarisation erronée

La semaine des examens du BAC commençant par ses fameuses épreuves de philosophie (matière qui offre des débouchés forts intéressants ), ce billet sera plus d’humeur que technique.

D’ailleurs, il semblerait que cette semaine soit source à réflexion 😉
Donc deux bonnes lectures a ajouter à votre escarcelle :

http://blog.domadoo.fr/index.php/domotique/1271-quest-ce-que-la-domotique
http://www.domotique-info.fr/2013/06/domotique-interoperabilite-m2m-api-socket-ip/

Nous le savons tous, la domotique c’est pour demain (oui, cela fait des années que c’est demain).
Heureusement, ce demain se dessine de plus en plus grâce tout d’abord à un engouement porté par des passionnés de plus en plus nombreux qui, magie du Nain Ternet aidant, le relaie sur des blogs et forums.
Par des médias qui commencent doucement à en parler sur des chaînes tout public, et surtout par des constructeurs/distributeurs qui se sont dit que le créneau pouvait être porteur et ont donc commencé a offrir des offres packagées permettant au tout venant de s’initier au bienfait de la domotique chez soi.

Tout cela est bien, on ne peut pas dire le contraire. L’idée fait son chemin dans la tête de plus en plus de personnes pour qui la domotique n’était qu’une vaste idée de geeks technophiles accros aux dernières nouveautés et pour lesquels le fait d’allumer une lampe avec son pc par une url dans son navigateur était aussi excitant qu’un ping vers un serveur externe à moins de 10ms.

Oui mais pour ce commun des mortels, pour qui un pc est sous windows et un accès à internet est une boite noire (ou blanche ou translucide, bref un tupperware qui prend la poussière sur une étagère) qu’on branche sur la prise du téléphone, la domotique reste un gadget et je le comprend.
Après tout, allumer la lampe du salon avec son smartphone, c’est très con. Si, si, je vous assure.

 

Alors pour vulgariser la domotique et la rendre attrayante auprès du grand public, les constructeurs/distributeurs ont décidé de mettre en oeuvre une stratégie mercantile apte à rentabiliser les heures passées par les équipes de R&D (Rapporte de l’argent et Démerde toi pour que cela ne me coûte rien).
Un environnement domotique comprend des équipements de confort (télécommande, prise commandée, sonde de température, douille commandée, volets roulants ou portails automatisés etc..) et des équipements de sécurité (détecteur de mouvement, d’ouverture, de fuite d’eau, de gaz ou de fumée ).

A partir de ce concept assez basique,  les chefs de projets/commerciaux se sont dit :
– « Comment qu’on va vendre ça a Mme Michu ? On va quand même pas lui dire qu’elle peut gérer les prises électriques de sa maison ! ».
– « Non mais attends Roger ! On va vendre ça comme une alarme apaschère !!! »
– « Génial Brandon ! Vendons leur ça ! »
Car oui, l’idée absolument géniale qui va révolutionner le monde et amener la domotique chez les gens, c’est de leur parler « sécurité » !
Après tout, c’est un constat évident, les français ont un sentiment d’insécurité et on nous le rabache sans cesse.

Pain béni pour ses constructeurs de solution domotique et des équipement de « sécurité » qui en font partie, le leitmotiv commercial devenu bien rodé qu’ils ont décidé de nous asséner est la possibilité justement de détecter et prévenir de toutes intrusions à domicile.
Que je te vende des caméras ip/wifi, des possibilités de visionner les flux sur son smartphone, d’être prévenu par SMS d’une intrusion chez moi et que sais-je encore, les solutions domotiques de nos chers constructeurs/fabricants se sont rapidement transformées en alarme à domicile, moins cher qu’une vrai alarme (après tout je m’en fous qu’elle soit neutralisable en quelques secondes ou ne résiste pas à un coup de marteau ou un évier rempli d’eau), elle est devenu la solution de protection de sa maison a moindre coût.

Le plus gênant, c’est que cette stratégie a plutôt bien marché puisque même certains constructeurs d’alarmes ont décider d’intégrer des possibilités de controle de prise électrique sur leurs solutions
Car peu de particulier disposent d’une alarme à domicile (étonnant non ?) et les fabricants d’alarmes qui ont difficilement réussi à promouvoir leur solution au sein des foyers se sont dit qu’ils avaient peut-être louper le coche, malgré les sommes engagées dans la certification de leur produits à des attaques de tout genre, non, ce qui semble intéresser le client lambda, c’est que son smartphone sonne quand quelqu’un rentre chez lui, au détriment de la résistance du produit d’alarme et de sa capacité à éloigner un intrus (ceux qui ont entendu la sirène d’alarme d’une blyssbox me comprendront…).
Et bien entendu, les assureurs suivent le pas tracé dans le sable du business.

Dans les forums ou discussions sur la domotique, c’est d’ailleurs l’une des premières préoccupations des « nouveaux » qui s’essayent à ce concept. Loin de privilégier une autre piste, les premières questions portent quasiment toujours sur les équipements de sécurité, les caméras et les sirènes.

La domotique se trouvent donc t-elle condamnée à être confiner comme une alarme low-cost au détriment de ses autres possibilités parce que le choix stratégique commercial des principaux constructeurs/fabricants est d’en promouvoir le côté sécuritaire ?
Peut-être, et c’est bien dommage, car c’est un mauvais choix et sûrement pas la meilleure façon de vulgariser la domotique, de la rendre attrayante et de lui rendre ce pour quoi elle est a été conçue.

 

Ne nous méprenons pas. Je ne dénigre aucunement les capacités de détections d’un équipement domotique et la facilité de sa mise en oeuvre pour être alerter d’une effraction chez soi.
Mais n’est-il pas particulièrement réducteur d’en faire le cheval de bataille de la domotique ?
Est-ce par cette voie (voix s’appliquant aussi 😉 ) que l’on fera comprendre la domotique aux gens ?
Non. Définitivement non.

La domotique a plusieurs rôles qui sont complètement occultés par cette approche sécuritaire.

  • Un rôle d’économie d’énergie à son domicile.
    La gestion de son chauffage beaucoup plus finement que ne le ferait n’importe quel thermostat d’ambiance. La coupure automatique de lampes restaient sournoisement allumées après avoir quitter une pièce. L’extinction d’appareil électrique qui n’ont pas vocation a être alimenter en permanence (et par la même la sécurité électrique d’une, par exemple, cafetière laisser en marche…).
  • Un rôle d’information et de prise en compte des données de son domicile. Température de chaque pièce (et par la même d’une isolation peut être déficiente a un endroit). Consommmation d’eau (et détection d’une surconsommation signe d’une fuite discrète). Consommation énergétique (électricité, gaz, fioul) en temps quasi réel et la prise de conscience subjacente des postes de dépenses.
  • Une centralisation de ses multiples données  (senseurs, équipements et vêtements connectés…) qui permettront un stockage et une analyse fines de toutes ses informations pour une traitement « a posteriori » (http://www.cityzensciences.fr/ sera a suivre dans les mois qui viennent)
  • Une automatisation des habitudes qui peuvent naturellement être délégués à un système domotique, avec un soupçon de cognitivité qui pourrait vous surprendre.

Enfin, et surtout, la force de la domotique pour laquelle le discours ne se veut malheureusement pas assez convaincant : les scénarios.

Car la puissance de la domotique vient justement de l’interopérabilité entre tout ce qui « fait » notre vie à la maison. Le fameux IFTTT (If Then Then That (si ça, alors fait ça).

– « S’il y a du vent supérieur à telle vitesse alors ferme les volets »
– « S’il est plus de 23h et que je sors de ma chambre pour aller aux toilettes, allume la lumière du couloir et des wc qu’a 20% de sa puissance »
– « Si ma grand-mère, chez elle, n’a pas ouvert sa boite de médicaments au repas du midi et/ou qu’elle n’a pas allumer un équipement électrique/ouvert un tiroir/frigidaire/placard depuis plus de 3h, alerte moi »
– « Si je suis en vacances alors n’ouvre pas les volets automatiquement à 7h, ne met pas mon réveil en route et coupe mon téléphone jusqu’à ce que j’ouvre mon frigo »
– « S’il fait beau demain, fait moi penser à acheter du charbon de bois pour le barbecue et profites en pour regarder si 2-3 potes seraient partant pour passer manger une merguez autour d’un bon bordeaux dont, bien sûr, tu auras vérifier que sa vieillesse se sera dérouler correctement en supervisant la température, la luminosité et l’hygrométrie de ma cave a vin ».
Etc, etc…

Ce manque de communication sur la possibilité de ces scénarios, sur des exemples de mise en place, de démonstration dans la vie quotidienne est un manque cruel des capacités réelles et avérées de la domotique en 2013.

Cantonner la domotique a un simple rôle de sécurité est dégradant au vue des possibilités du concept.
Rendre abordable, facile, compréhensible la création et la gestion de divers scénarios devrait être aussi simple que la mise en place de 3 détecteurs de mouvements couplés à une alerte SMS que se targue de vendre nos chers constructeurs/distributeurs.

C’est à nous tous, utilisateurs, contributeurs, passionnés de domotique de relayer ses possibilités auprès du public et de ne pas laisser quelques entreprises commerciales vulgariser un concept qui n’est vraiment pas le bon.

A ce genre de jeu, certains s’étaient essayer avec succès dans les années 80/90 avant que les passionnés et vrais utilisateurs en reprennent le contrôle et clame haut et fort qu’un autre chemin était possible et sûrement le mieux. Cela s’appelait, les débuts de l’informatique.

Classé dans domotique | Taggé , , , | 14 Commentaires
Mar 18

Monter votre Hubic dans un répertoire Linux

Un petit billet vite fait suite a l’avalanche de mails que j’ai reçu après mon tweet sur mon montage local de mon dépot Hubic.

Apparemment, cette technique semble très recherchée actuellement (surtout depuis l’abandon du support « non officiel » webdav de Hubic).

Donc je vais vous expliquer rapidement, comment monter votre dépôt Hubic sous Linux, et l’utiliser comme un simple répertoire local (synchro comprise).

Hubic utilise Open Stack, un projet opensource axé sur le « cloud computing ».

A ce titre on pourrait imaginer qu’il est totalement compatible avec les librairies OpenStack (comme Swift), mais en fait, pas vraiment…

Si, intrinsèquement, le client Swift fonctionne, OVH a rajouté une couche  supplémentaire d’authentification à base de token, et ça, c’est pas vraiment bien géré par Swift.

Heureusement, des confrères bloggeurs comme Vincent Giersch ou Toorop ont proposé des solutions pour s’authentifier sur Hubic via Swift.

Toorop propose même une passerelle de pré-authentification en libre service pour votre Hubic, mais dans notre cas, nous allons tout gérer en interne.

  • Gérer en interne la pré-authentification Hubic

Je me suis basé sur l’excellent travail de Toorop et son HubicSwiftGateway.

Télécharger les sources :

https://github.com/Toorop/HubicSwiftGateway

Décompresser le tout et copier l’intégralité du contenu du répertoire « www » dans un des répertoires de votre serveur web local (ah bah oui, je suppose quand même que vous avec un petit serveur web dans votre réseau interne… (et qui supporte php aussi…)
Un niveau au dessus, il vous faut créer un répertoire « cache » avec les droits 777 (je sais c’est crade… mais bon, ca reste du local)

Pour ma part, j’ai tout déposé dans le répertoire « hubic » et la gateway est donc accessible via http://lan.web/hubic (et donc le cache sur http://lan.web/cache)

Dès maintenant vous pouvez utiliser le client Swift officiel en ligne de commande (y’a que ça de vrai) grâce a un :

swift -A http://lan.web/hubic/ -U loginhubic -K motdepassehubic

Je vous conseille un petit « alias hubic= … » dans votre .bashrc 😉

et donc un « hubic list » vous donnera la liste de vos fichiers.

(ou swift -A http://lan.web/hubic/ -U loginhubic -K motdepassehubic list , si vous aimez taper au clavier)

bref, swift -h pour l’aide ou le site web 🙂

  • Installer cloudfuse

Michael Barton nous offre une petit bout de code bien sympa permettant de monter sous linux des stockages distants type Rackspace (et Swift également) via la bibliothèque FUSE.

Télécharger les sources de CloudFuse ici :

https://github.com/redbo/cloudfuse

Préparer les pré-requis sous notre nunux favori :
libcurl, libcurl-devel, fuse, fuse-devel, fuse-libs, libxml2 et libxml2-devel

Installation comme je les aime :

tar xvzf redbo-cloudfuse-809b07e.tar.gz
cd redbo-cloudfuse-809b07e
./configure
make
make install

Un petit fichier de config dans votre home directory (.cloudfuse) :

username=loginhubic
api_key=motdepassehubic
authurl=http://lan.web/hubic/
cache_timeout=20

Et voila, ne reste qu’a se mkdir un /mnt/hubic

et la commande magique… tadammm :

/usr/local/bin/cloudfuse /mnt/hubic/ -o noauto_cache,sync_read

(bon je vous laisse lire le man de cloudfuse si vous voulez peaufiner ;))

Et voila, vous avez votre Hubic directement sous /mnt/hubic.
Créer ou supprimer un fichier et vous le retrouverez synchroniser avec vos autres clients Hubic officiels 😀

Magique non ?

Amusez-vous bien 😉

Classé dans linux | Taggé , , , , | 59 Commentaires
Mar 10

S.A.R.A.H. , Contrôler votre domotique autrement

Un retour à la domotique en attendant la suite de mon billet système qui me prend plus de temps de rédaction que prévu :p
Que voulez-vous, on se laisse aller à tester plein de trucs et le temps file plus vite que l’on ne le souhaiterait…

Aujourd’hui je vais vous présenter un projet dont vous avez sûrement entendu parler si vous côtoyez l’actualité domotique, S.A.R.A.H.

S.A.R.A.H. (Self Actuated Residential Automated Habitat) est un framework écrit en C# pour Windows, basé sur les API de reconnaissance vocale Speech API et le SDK de la Kinect de Microsoft.

Et la vous vous dites, le GuiguiAbloc, il a pété un câble, il parle de windows sur son blog et il met même des liens vers Micro$oft !!!

C’est pas faux…

J’avoue que j’ai trainé des pieds avant de tester le projet de Jean-Philippe Encausse à cause de ma révulsion envers celui dont on peut pas citer le nom, mais il faut bien se rendre à l’évidence, la reconnaissance vocale sous Linux, c’est une horreur.
A part des POCs a 2 balles ou des démos du M.I.T., je n’ai pour l’instant vu personne faire un(e) tuto/démonstration tout simple pour faire de la reconnaissance vocale sous mon OS fétiche (si toi aussi tu as essayer de te configurer Sphinx le soir au fond des bois, tu me comprendras…)

Bref, mes aversions mises de côté, il faut se rendre a l’évidence, ce Monsieur a fait un travail époustouflant.

Ca me réconcilierais presque avec Micro$oft (nan j’déconne).

S.A.R.A.H. permet de contrôler votre domotique par la voix, par les gestes, par la reconnaissance faciale (en cours), par des QR codes etc…
En gros, toutes les possibilités énormes de la Kinect sont exploitées pour interagir avec votre domotique et bonus, elle vous répond (bon d’accord ça fait une femme de plus a causer dans la maison, je vous l’accorde)

En gros, il suffit de dire « Sarah, allume la lumière du salon » et « Sarah, lis le film la Cambrioleuse » pour que xbmc lance votre film favori sous le doux éclairage de votre halogène.

Intéressant, non ?

Concernant l’architecture de S.A.R.AH., vous trouverez tout ce qu’il vous faut ici:

http://encausse.wordpress.com/s-a-r-a-h/s-a-r-a-h-architecture/

Je ne rentrerais pas dans les détail du projet, le site de l’auteur vous l’expliquera mieux que moi, vidéo à l’appui, mais je vais plutôt vous parlez de sa mise en oeuvre ainsi que de la création d’un plugin tout simple pour s’intercaler avec un webservice qui interrogera une base de données.

Car si j’ai une remarque à formuler, c’est le côté léger de la documentation pour l’installation et l’utilisation, surtout quand, comme moi, on n’a pas toucher un Windows depuis 1993…

Tout d’abord, il vous faut un windows, Seven de préférence.
J’ai personnellement installé un windows 7 32bits tout ce qu’il y a de plus basique, sans fioritures, sur un ordinateur portable avec 2Go de RAM (ce qui me permet de profiter du micro intégré).

Ensuite, les pré-requis (bien sûr, installer les versions x64 si vous êtes sous un windows en 64bits) :

– Le framework Microsoft .Net 4.5

– Le SDK Microsoft Speech Platform (j’ai installé la version 11)

– Le Speech Platform Runtime (version 11 également)

– Le pack de langue Française

– les runtime Kinect

En résumé, voici ce que j’ai d’installer pour faire tourner S.A.R.A.H.

 

Ensuite je vous conseille fortement de configurer la reconnaissance vocale de Windows 7  pour être sur que tout fonctionne correctement.

http://windows.microsoft.com/fr-fr/windows7/set-up-speech-recognition

Ne reste qu’a récupérer le programme S.AR.A.H

Dézipper le (j’ai tout mis dans c:\sarah).

– Installer la voix française « Virginie » inclus dans le répertoire README/ScanSoftTTS
(je vous conseille d’ailleurs de régler la voix de synthèse vocale dans les paramètres Windows http://windows.microsoft.com/fr-fr/windows7/setting-speech-options )

Puis lancer le WSRNode.bat

Si vous n’avez pas autant de plugins qui se lance, rassurez vous, cela s’installe après

Puis le WSRMicro.bat (si comme moi vous n’avez qu’un micro, sinon le WSRKinect.bat si vous avez la kinect).

L’icône d’une petite maison doit apparaître dans la barre des tâches et si vous faites un clic droit dessus, vous pouvez lancer « Sentinel » qui permet de visualiser en direct les logs du programmes.

A vous de jouer maintenant pour essayer S.A.R.A.H en testant le plugin « time » déjà inclus :

Dites « Sarah, quelle heure est-il ? » et elle devrait vous donner l’heure 😀 Magique non ?

Si cela ne fonctionne pas, regarder ce qui défile dans la console Sentinel, cela devrait vous aider a débugger. Sachez que le groupe de discussion est là pour vous aider 🙂

Maintenant que cela fonctionne, vous pouvez ajouter des plugins via l’interface web (http://127.0.0.1:8080), dans le « Store ».
Ces plugins s’installeront dans le répertoire « plugins » (dingue, non) et leur structure est toute simple.

Nous allons donc ensemble créer un plugin tout simple qui va me permettre d’interroger S.A.R.A.H pour connaître la température ou le degré d’hygrométrie dans une pièce de la maison.

Toutes les données de mes sondes de températures sont enregistrées dans une base MySQL grâce au client xpl-mysql-logger.
La structure de la table est toute simple :

mysql> desc sensor ;
+----------------+--------------+------+-----+---------+----------------+
| Field          | Type         | Null | Key | Default | Extra          |
+----------------+--------------+------+-----+---------+----------------+
| idx            | int(11)      | NO   | PRI | NULL    | auto_increment |
| curDate        | date         | YES  |     | NULL    |                |
| curTime        | time         | YES  |     | NULL    |                |
| sensorType     | varchar(10)  | YES  |     | NULL    |                |
| sensorLocation | varchar(255) | YES  |     | NULL    |                |
| sensorValue    | varchar(25)  | YES  |     | NULL    |                |
| sensorUnit     | varchar(25)  | YES  |     | NULL    |                |
+----------------+--------------+------+-----+---------+----------------+
7 rows in set (0.00 sec)

Pour interroger cette base de données, on va vite fait s’écrire un Webservice en python :

simplews.py

#!/usr/bin/env python
# Grouik coded by GuiguiAbloc
 
import web, MySQLdb
import re,socket,sys,os
web.config.debug = False
urls = (
'/', 'index',
'/temp/(.*)', 'temp'
)
 
render = web.template.render('templates/', globals={'re':re})
app = web.application(urls, globals())
 
class index:
def GET(self):
return web.HTTPError(403)
def POST(self):
return web.HTTPError(403)
 
class temp:
def GET(self,id):
db = web.database(dbn='mysql', user='sensor', pw='sensor', db='sensor')
todos = db.query("SELECT * from sensor where sensorType=$toto ORDER BY idx DESC limit 1", vars={ 'toto' : id})
for todo in todos:
return todo.sensorValue
 
if __name__ == '__main__':
app.run()

Ne reste qu’a le lancer en spécificant le port d’écoute:

python simplews.py 8085

et une simple requête http du type :

http://serveur;8085/temp/TempSalon interrogera la base de données et vous retournera la valeur associée à l’entrée TempSalon :

$ curl http://serveur:8085/temp/TempSalon
20.7
 
# python simplews.py 8085
http://0.0.0.0:8085/
192.168.0.10:58311 - - [10/Mar/2013 17:30:49] "HTTP/1.1 GET /temp/TempSalon" - 200 OK

Maintenant que nous avons un webservice, écrivons un petit plugin pour S.A.R.A.H.

Dans c:\sarah\plugins, nous allons créer le répertoire « temperature ».

Ce répertoire contiendra 3 fichiers :

temperature.prop (qui est le descriptif du plugin)

{
"modules" : {
"temperature":     {
"description": "Lit des infos provenant de la bdd",
"version"    : "0.1",
"api_url"    : "http://serveur:8085/temp"
}
}
}

temperature.js (qui est le script js qu’exécutera S.A.R.A.H)

exports.action = function(data, callback, config){
 
// Retrieve config
config = config.modules.temperature;
if (!config.api_url){
console.log("Missing temperature config");
return;
}
 
console.log("temperature config complete");
var periphId;
if (data.room == "salon") {
var place = "le salon";
if (data.type == "T") {
var mesure = "la température";
periphId = "TempSalon";
}
}
 
if (data.room == "dehors") {
var place = "le jardin";
if (data.type == "T") {
var mesure = "la température";
periphId = "TempExt";
}
if (data.type == "H") {
var mesure = "le taux d'humidité";
periphId = "HygroExt";
}
}
 
// Build URL
var url = config.api_url;
url += '/'+periphId;
 
console.log('URL:' + url);
 
// Send Request
var request = require('request');
request({ 'uri' : url }, function (err, response, body){
 
if (err || response.statusCode != 200) {
callback({'tts': "Désolé , je ne parviens pas récupérer  " + mesure + "dans " + place});
 
return;
}
// Callback with TTS
console.log("Page : " + body);
console.log(data.type + " : " +body);
var value = body;
callback({'tts': mesure + " est de " + value + data.unit + " dans " + place});
});
}

Et enfin, le temperature.xml qui configure les phrases sur lesquelles S.A.R.A.H. doit réagir :

<grammar version="1.0" xml:lang="fr-FR" mode="voice" root="ruletemperature" xmlns="http://www.w3.org/2001/06/grammar" tag-format="semantics/1.0">
  <rule id="ruletemperature" scope="public">
 
<example>Sarah combien fait-il dans le salon</example>
    <tag>out.action=new Object(); </tag>
    <item weight="2">Sarah</item>
    <one-of>
<item>Quelle est la temperature dans out.action.type="T"out.action.unit="degrés"
</tag></item>
<item>Quelle est la temperature out.action.type="T"out.action.unit="degrés"
</tag></item>
<item>Combien fait-il dans out.action.type="T"out.action.unit="degrés"
</tag></item>
<item>Combien fait-il out.action.type="T"out.action.unit="degrés"
</tag></item>
<item>Quel est le taux d'humidité out.action.type="H"out.action.unit="pourcents"
</tag></item>
<item>Quelle est l'humidité out.action.type="H"out.action.unit="pourcents"
</tag></item>
<item>Quelle est l'hygrométrie out.action.type="H"out.action.unit="pourcents"
</tag></item>
 
</one-of>
    <one-of>
 
<item>le salonout.action.room="salon"
</tag></item>
<item>dehorsout.action.room="dehors"
</tag></item>
</one-of>
<tag>out.action._attributes.tts="Je regarde tout de suite";
</tag>
<tag>out.action._attributes.uri="http://127.0.0.1:8080/sarah/temperature";
</tag>
</rule>
</grammar>

Vraiment tout simple non ?

Pour vous donner un aperçu de ce que cela donne, je vous colle une petite vidéo vite faite 🙂


Démonstration S.A.R.A.H. par Guiguiabloc

Bref un excellent projet, qui fonctionne parfaitement et je compte continuer mes expérimentations avec une Kinect, histoire de voir ce que cela donne 😀

Amusez-vous bien 😀

Classé dans domotique | Taggé , | 15 Commentaires
Fév 04

Haute-disponibilité et Load-Balancing par Cascade de NS

©Disney/Pixar

 Un retour aux premiers amours de ce blog, avec, pour changer, une suite de billets système et réseau.

Cette série est issue d’une petite discussion que j’ai eu avec mon ami Horacio, du blog LostinBrittany, durant un projet technique professionnel commun.
Plutôt que de garder pour moi mes réflexions, autant vous les faire partager 🙂

Cette discussion concerne surtout le prochain billet de ce blog, mais avant de l’aborder, il fallait poser les bases d’une certaine architecture et c’est ce que nous allons tout d’abord voir aujourd’hui.

Je vais vous parler d’une technique qui paraît bien triviale mais étonnamment efficace et largement employée dans les architectures disposant de 2 branches d’accès Internet.

Après tout, dans votre soucis constant de disposer d’une architecture hautement disponible et partant du sacro-saint adage « on ne met pas les oeufs dans le même panier », vous avez décidé de confier l’accès internet de votre infrastructure à deux opérateurs différents (par exemple, si  > 2, cela marche aussi…)

Bien évidemment, cela peut aussi être l’hébergement de vos serveurs dédiés chez deux entités différentes, ou encore, plus simplement, des serveurs dédiés dans 2 datacenters différents, ou tout bêtement, de 2 serveurs dédiés devant lesquelles vous n’avez pas de load-balancer…

Quoi qu’il en soit, la multiplication des points d’entrées « Internet » de votre service sur plusieurs chemins différents, vous donne, déjà, une meilleure sérénité de sa disponibilité envers le « monde ».

L’inconvénient de ce choix est qu’il est difficile de positionner un Load-Balancer devant vos serveurs pour répartir la charge ou tout simplement de renvoyer tout le trafic sur le serveur « vivant » quand l’autre est tombé.

On ramenant le concept à deux serveurs web (que je vais utiliser pour un exemple plus « accessible » ), nous allons voir comment utiliser le service DNS pour aller sur l’un ou l’autre des serveurs et pouvoir basculer le trafic sur l’un des deux en cas de panne d’un accès (ou du décès de l’un des serveurs Web).

Dans un vision très habituelle des choses, que l’on rencontre fréquemment sur les architectures exposées par les sysadmins, la technique souvent utilisée est le « Round Robin DNS« .

Je vous rassure tout de suite, rien à voir avec des problèmes d’obésité d’un quelconque défenseur de la fôret de Sherwood, mais d’une bidouille d’un enregistrement dns.

En effet, pour un enregistrement de type A (un enregistrement DNS spécifiant un nom = une adresse IP  pour faire simple), on peut donner 2 entrées pour le même nom.

Exemple :

blog.guiguiabloc.fr  IN A 10.10.10.10
blog.guiguiabloc.fr  IN A 10.20.20.20

Les plus pointus allant même jusqu’à modifier l’entrée TTL pour peaufiner.

Résultat, alternativement, les requêtes sont envoyées sur 10.10.10.10 ou sur 10.20.20.20.

Le gros inconvénient de cette technique est que les requêtes iront toujours sur l’un ou l’autre, même si l’un des deux est mort… Un accès sur 2 n’aura donc pas de réponse… Gênant.
C’est donc une technique « a pas cher » de load-balancing, mais nullement une solution de haute-disponibilité (ou de Fail-Over).

Alors comment utiliser les DNS pour faire et du load-balancing et du fail-over ?
La réponse s’appelle du « Cascading NS » (ou cascade de serveurs NS).

Si une entrée DNS de type A fait la correspondance entre un nom d’hôte et une adresse IP, un enregistrement de type NS vous donne le serveur DNS ayant autorité sur le domaine (et qui donc sera à même de vous donner l’adresse IP (ou type A) du nom d’hôte que vous recherchez ou de vous indiquez à qui le demander).

Un dessin valant un long discours, regardons un peu le fonctionnement du cascading NS :

Que se passe t-il quand le client demande « blog.guiguiabloc.fr » ?

– Les autorités TLD répondent que le domaine « guiguiabloc.fr » est géré par les NS de tel registrar (OVH, GANDI, etc…) (je simplifie hein :p)

– Les serveurs DNS du Registrar répondent qu’il faut interroger deux autres NS, NS1.mondns.fr et NS2.mondns.fr qui sont autorité de zone pour le domaine « guiguiabloc.fr » (on arrive la sur VOS serveurs DNS) (1)

– Les serveurs DNS, ns1.mondns.fr et ns2.mondns.fr répondent qu’ils gèrent bien le domaine « guiguiabloc.fr » mais le sous-domaine « blog.guiguiabloc.fr » est géré par deux autres DNS, web-1.mondns.fr et web-2.mondns.fr (qui sont vos serveurs Web sur lesquelles tournent un serveur DNS ne s’occupant que de cette zone) (2)

– Le client interroge alors l’un des NS (web-1.mondns.fr ou web-2.mondns.fr) pour connaitre l’entrée A de blog.guiguiabloc.fr (3)

– Si c’est web-1.mondns.fr qui est interrogé, il répondra 10.10.10.10, si c’est web-2.mondns.fr, il répondra 10.20.20.20, avec une durée de vie d’1 minute de la correspondance (60 secondes plus tard, si le client doit demander de nouveau blog.guiguiabloc.fr, il devra demander de nouveau l’adresse IP (lors d’une nouvelle session par exemple).

Voila ce que donnera une demande de résolution :

guigui@Clara:~$ dig blog.guiguiabloc.fr
 
; <<>> DiG 9.7.3 <<>> blog.guiguiabloc.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41551
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
 
;; QUESTION SECTION:
;blog.guiguiabloc.fr.              IN      A
 
;; ANSWER SECTION:
blog.guiguiabloc.fr.       49      IN      A       10.10.10.10
 
;; AUTHORITY SECTION:
blog.guiguiabloc.fr.       49      IN      NS      web-1.mondns.fr.
 
;; ADDITIONAL SECTION:
web-1.mondns.fr.         3922    IN      A       10.10.10.10

Et 60 secondes plus tard :

...
;; ANSWER SECTION:
blog.guiguiabloc.fr.       60      IN      A       10.20.20.20
 
;; AUTHORITY SECTION:
blog.guiguiabloc.fr.       60      IN      NS      web-2.mondns.fr.
 
;; ADDITIONAL SECTION:
web-2.mondns.fr.         5006    IN      A       10.20.20.20

Vous avez compris que le site web blog.guiguiabloc.fr tourne sur les deux serveurs web avec chacun une IP différente.

A l’inverse du Round-Robin DNS, le client interroge les NS aléatoirement et prend la réponse du plus rapide (et donc également du plus proche géographiquement).
Rassurez vous, toute cette séquence ne prend que quelques millisecondes.

Mais que se passe-t-il quand web-1.mondns.fr tombe (et donc ne peut plus répondre).

 Le début est identique mais quand le client demande « blog.guiguiabloc.fr »  aux serveurs NS de la sous-zone, seul le « NS » 2 répondra.

Vous avez la un fail-over immédiat (tout au moins a 60 secondes après le crash) puisque NS1 ne répondra jamais.
La technique est aussi très efficace quand vous souhaitez retirer un des serveurs web de votre pool, il vous suffit d’arreter le serveur DNS dessus. Il ne répondra plus aux requètes NS et donc ne prendra pas de trafic 😀

La configuration des DNS est des plus basiques pour cela, il faut bien évidemment que les serveurs DNS de web-1.mondns.fr et web-2.mondns.fr soit chacun master (maître) (puisqu’ils donnent une entrée de type A différente).

Pré-requis, vous avez bien entendu défini une entrée de type A pour web-1 et web-2 dans la zone « mondns.fr ».

Sur vos serveurs DNS principaux (ns1.mondns.fr et ns2.mondns.fr), pour la zone « guiguiabloc.fr » (bien sûr remplacez tout cela par vos domaines/IP 😉 )

$TTL 600
@                IN SOA  ns1.mondns.fr. noc.mondns.fr. (
2013020400 ; serial
3600       ; refresh
3600       ; retry
3600000    ; expire
3600       ; minimum
)
 
IN NS ns1.mondns.fr.
IN NS ns2.mondns.fr.
blog                  IN NS web-1.mondns.fr.
                        IN NS web-2.mondns.fr.

Sur web-1, pour la zone « blog.guiguiabloc.fr » :

$ORIGIN .
$TTL 60
blog.guiguiabloc.fr                IN SOA  ns1.mondns.fr. noc.mondns.fr. (
2013020400 ; serial
3600       ; refresh
3600       ; retry
3600000    ; expire
3600       ; minimum
)
 
IN NS          web-1.mondns.fr.
IN A       10.10.10.10

Sur web-2, pour la zone « blog.guiguiabloc.fr »

$ORIGIN .
$TTL 60
blog.guiguiabloc.fr                IN SOA  ns1.mondns.fr. noc.mondns.fr. (
2013020400 ; serial
3600       ; refresh
3600       ; retry
3600000    ; expire
3600       ; minimum
)
 
IN NS          web-2.mondns.fr.
IN A       10.20.20.20

Bien entendu, je vous laisse adapter à votre configuration, c’est juste un exemple 🙂

Alors, elle n’est pas sympa cette technique ? 🙂

« oui,oui. Très sympa oh Grand Guiguiabloc, mais y’a quand même un problème ! »
« Ah ? Je t’écoute jeune Padawan »
« si le service web de web-1 plante par exemple, mais pas le serveur, mon DNS il répond toujours !!! et les visiteurs ils arrivent toujours sur mon serveur !! Ca craint ! »
« Je m’attendais à cette remarque, jeune youglin, et comme je suis dans une année de grande bonté, je vais te donner une solution pour cela »

« oh merci Grand Guiguiabloc !!! » (flap-flap-flap)

La solution pour couper votre DNS local sur votre serveur web (ou votre reverse-proxy hein) en cas de crash du service http s’appelle :
MONIT.

MONIT est un utilitaire qui surveille vos process (mais également vos répertoires, fichiers, programmes etc..) et execute des actions en cas de soucis.

L’action la plus courante est d’avertir l’admin (forcément :p) mais également par exemple, de tenter de relancer le programme.

Exemple pour surveiller le process Nginx

check process nginx with pidfile /var/run/nginx.pid
  start program = "/etc/init.d/nginx start"
  stop program  = "/etc/init.d/nginx stop"
  group www-data

Vous trouverez des exemples sur la page wiki du projet :

http://mmonit.com/wiki/Monit/ConfigurationExamples

En cas de non réponse du process, vous pouvez appeler un script par « exec » ‘de type « /etc/init.d/bind9 stop » 😉

Plus simple encore, un simple script bash appeler en crontab :

#!/bin/bash
#pre-requis blog.guiguiabloc.fr a une entrée dans
#le fichier /etc/hosts avec son ip locale
#pour éviter d'interroger les DNS
TESTING=`curl -sL -w "%{http_code} %{url_effective}\\n" "blog.guiguiabloc.fr" -o /dev/null`
if test "$TESTING" != "200 http://blog.guiguiabloc.fr"
then
echo "CA CHIE"
else
echo "ok"
fi

Et donc arreter le service DNS si « CA CA CHIE » 😀

En espérant que cela vous donne des idées

Amusez-vous bien 😀

 

 

Classé dans architecture, linux | Taggé , | 22 Commentaires