Route53 le dns de chez Amazon

Description du service
  • 4 Serveurs de noms utilisés
  • Modification des enregistrements via api amazon
  • 37 serveurs dns à travers le monde
Vérifications de l'état de santé :

Vérifications http classiques sur la terminaison :

  • 0,75 USD* par vérification de l'état et par mois

Comment amzon vérifier si le serveur est en vie ?

http://docs.aws.amazon.com/Route53/...

En HTTP ou HTTPS, il faut recevoir un code 200 ou en dessous de 400, pour que le serveur soit considéré comme vivant.

Les différents modes : http://docs.aws.amazon.com/Route53/...

Possibilité d'avoir un site uniquement en "backup" : désolé ce site est en panne..

  • Seuil d'echecs : 3 par defaut, possibilité de montrer à 10 checks
  • Dès que la ressource redeviens UP : 3 Checks puis changement de l'ip
  • interval de check : de 10 à 30 secondes

En cas de panne :

  • Envoi d'un mail d'alerte
Redondance du service

Redondance, via des ip de serveurs DNS utilisant anycast

  • Réponse selon les conditions du réseau (Exemple : FranceIX down :))
Equilibrage de charge DNS : WRR (Weighted Round Robin)

Il est possible d'attribuer un poids aux réponses d'un enregistrement A.

50/50 :

  • deux ip en réponse
  • chaque ip prends 50% des réponses
Limitations :
  • 500 zones dns
  • 10 000 Enregistrements DNS
ipv4 / ipv6

Aucun souci pour les deux

DNSSEC

pas de DNSSEC chez Amazon route 53

TTL amazon route 53
  • 60 secondes par defaut
  • possibilité de mettre plus
Tarifs
  • 0,50 USD par zone hébergée / mois pour les 25 premières zones hébergées
  • 0,10 USD par zone hébergée / mois pour chaque zone hébergée additionnelle

Requêtes standard :

  • 0.400 USD par million de requêtes – premier milliard de requêtes/mois
  • 0.200 USD par million de requêtes – au-delà d'un milliard de requêtes/mois

Basés sur la latence :

  • 0.600 USD par million de requêtes – premier milliard de requêtes/mois
  • 0.300 USD par million de requêtes – au-delà d'un milliard de requêtes/mois

GeoDns :

  • 0.700 USD par million de requêtes – premier milliard de requêtes/mois
  • 0.350 USD par million de requêtes – au-delà d'un milliard de requêtes/mois
Estimer combien ça va vous coûter ?

http://calculator.s3.amazonaws.com/index.html

haproxy : les fonctionnalités fun !

Lisons un peu la doc d'haproxy

http://www.haproxy.org/download/1.3...

Adresse de sortie

Il est possible de forcer l'adresse utilisée pour établir les connexions vers les serveurs à l'aide du paramètre "source". Il est même possible de forcer le port, bien que cette fonctionnalité se limite à des usages très spécifiques. C'est particulièrement utile en cas d'adressage multiple, et plus généralement pour permettre aux serveurs de trouver le chemin de retour dans des contextes de routage difficiles. Si l'adresse est '0.0.0.0' ou '*' ou vide, elle sera choisie librement par le systeme. Si le port est '0' ou vide, il sera choisi librement par le système. Il est à noter que depuis la version 1.1.18, les tests de bon fonctionnement des serveurs seront aussi effectués à partir de la source spécifiée par ce paramètre.

Exemples :


   listen http_proxy *:80
          # toutes les connexions prennent l'adresse 192.168.1.200
       source 192.168.1.200:0
   listen rlogin_proxy *:513
          # utiliser l'adresse 192.168.1.200 et le port réservé 900
       source 192.168.1.200:900
Garantir la persistance
  1. assurer qu'une même adresse IP ira sur le même serveur pour tout service
   listen http_proxy
       bind :80,:443
       mode http
       balance source
       server web1 192.168.1.1
       server web2 192.168.1.2
  1. améliorer la persistance par l'utilisation de la source en plus du cookie :
   listen http_proxy :80
       mode http
       cookie SERVERID
       balance source
       server web1 192.168.1.1 cookie server01
       server web2 192.168.1.2 cookie server02
Monitoring des serveurs backend :
Il est possible de tester l'état des serveurs par établissement de connexion

TCP ou par envoi d'une requête HTTP. Un serveur hors d'usage ne sera pas utilisé dans le processus de répartition de charge interne. Pour activer la surveillance, ajouter le mot clé 'check' à la fin de la déclaration du serveur. Il est possible de spécifier l'intervalle (en millisecondes) séparant deux tests du serveur par le paramètre "inter", le nombre d'échecs acceptés par le paramètre "fall", et le nombre de succès avant reprise par le paramètre "rise". Les paramètres non précisés prennent les valeurs suivantes par défaut :

Les différentes méthodes de check http

 - option httpchk               -> OPTIONS / HTTP/1.0
 - option httpchk URI           -> OPTIONS <URI> HTTP/1.0
 - option httpchk METH URI      -> <METH> <URI> HTTP/1.0
 - option httpchk METH URI VER  -> <METH> <URI> <VER>

haproxy : serveur de backup

Contexte :
  • J'ai un serveur web
  • Si le serveur web tombe, je veux voir quelquechose.. une page de backup, un backup

Configuration :

frontend http-in
       bind *:8888
       mode http
       option forwardfor
        default_backend backend_default
     backend backend_default
        mode http
        option tcplog
        option httpchk GET /
        option httpclose
        option forwardfor
        balance static-rr
        maxconn 10000
        server freebox 192.168.0.254:80 maxconn 1000 weight 1 check
        server backup-freebox 192.168.0.13:8080 maxconn 1000 weight 1 check backup

Des stats :

listen stats :6666
  mode http
  stats enable
  stats hide-version
  stats realm Haproxy\ Statistics
  stats uri /
Tester la panne
iptables -A OUTPUT -d 192.168.0.254 -p tcp --dport 80 -j DROP*

haproxy ne peut plus voir le backend, il envoie donc les requêtes vers backup

fin du test :

iptables -D OUTPUT -d 192.168.0.254 -p tcp --dport 80 -j DROP

pour regarder les stats :

http://localhost:6666
Bonus : cluster de backup
option allbackups
      server backup-freebox 192.168.0.13:8080 maxconn 1000 weight 1 check backup
        server backup-freebox 127.0.0.1:81 maxconn 1000 weight 1 check backup

avec cette option

  • Le serveur backend est DOWN
  • On commence un équilibrage de charge sur les deux backup

Grenoble un câble 20 000 Volts au sommet de la Moucherotte

ERDF est en train de poser un câble 20 000 Volts jusqu'au sommet de la Moucherotte au dessus de Grenoble.

La pose du câble est effectué avec une trancheuse à une profondeur de 1 mètre. Puis remblayé immédiatement.

Ce câble va alimenter un radar météo d'une portée de 50 à 60 Km.

Selon CartoRadio, il s'agit du relais :

http://www.cartoradio.fr/cartoradio...

  • N° Identification 1175407
  • Description du support Pylône tubulaire / 17,0 m / Météo
  • Adresse LE SOMMET DU MOUCHEROTTE
  • Code Postal / Commune 38250 SAINT-NIZIER-DU-MOUCHEROTTE

Voici le relais en question :

Est-ce qu'un câble de fibre optique a été prévu ?

Voir la vidéo http://t.co/6YJKeuUWcC

erdf1.jpg

erdf2.jpg

erdf3.jpg

erdf4.jpg

erdf5.jpg

Un Fournisseur d'accès Rural qui est dans le #FAIRE b4rn.org.uk

Un fournisseur d'accès qui utilise le Do It Yourself

http://b4rn.org.uk/

Zone rurale, peu rentable.. personne n'allait le faire, ils ont décidé de monter leur propre fournisseur d'accès et de tout faire eux même !

Ils sont dans le FAIRE plutôt que nous, qui sommes dans l'attente du #FTTH pour tous en 2020..

Présentation du projet

Une zone rurale, avec des lignes cuivre de mauvaise qualité, personne qui n'investit pour aller vers la fibre. Ils ont donc décidé de créer une société :

  • Coopérative
  • Sans But Lucratif
  • Société de prestation pour la communauté (une forme de société je suppose)
  • L'argent retourne dans la communauté

En résumé c'est une coopérative pour l'intérêt général

Via les slides et via ces slides

Ambitions :

  • 1 Gb/s symétrique
    • Demain : 10 Gb/s 100 Gb/s selon les demandes
    • 100% des gens connectés
    • aucune propriété trop loin ou trop cher (Péréquation 100%)
  • Abordable : 190 € de frais daccès
  • 38 € par mois d'abonnement7
  • 1000 abonnés d'ici la fin de l'année
  • 1500 avec les tubes branchés (fibre non branchée)

Etat du réseau juin 2014

  • 787 abonnés
  • 500 en projet
  • Tubes et fibre : 520 Km

Décisions techniques :

  • FTTH
  • Point à point : 2 fibres par abonné
  • 8 points de mutualisation
  • Utilisations de tubes de 16 mm pour les dorsales
  • 144 ou 96 fibres
  • pas de parcours le long des routes (plutôt via les champs si on en croit toutes les photos)
  • Utilisations de tubes de 7 mm pour les dérivations de fibre

Décisions tech suite :

  • ethernet everywhere
  • Pas cher et bonne latence
  • Bon respect des standards, donc pas mal interopérable
  • Matériel low cost

Backbone

  • Réseau de nouvelle génération (1 Gb/s partout) donc.. beaucoup de connectivité nécessaire
  • Fibre noire louée vers Datacenter Telecity de Manchester
  • DWDM installé pour avoir 32 longueurs d'ondes
  • Chaque longueur d'onde peut supporter 100 Gb/s
  • Capacité totale : 3200 Gb/s
  • Peering à Telecity : Via http://www.edge-ix.net/ et LINX
  • Achat de transit à Telecity, avec des prix de gros
  • Schéma du Transit : https://www.robtex.com/as/as58273.h...
  • Mise en place de peering avec les gens qui font du CDN, Cache & co.. pour limiter l'achat de transit (Design BGP)
  • Chaque switch dispose de deux connexions aux routeurs du backbone et via des uplink 10GbE
  • 128 Km de fibre loués pour rejoindre Telecity
  • MUX de chez http://www.smartoptics.com/products...
  • Routeurs BGP Juniper MX240
  • Un AS attribué par le RIPE : AS58273
    • 3 prefix V4
    • 2 prefix V6
  • Les prefix :
*5.83.8.0/21
*5.83.8.0/22
*5.83.12.0/22

Schéma du réseau :

schema-reseau-b4rn.jpg

Leçons apprises

  • Obtenir un droit de passage des agriculteurs n'est pas difficile
  • Tout le monde pensait que ça allait être compliqué
  • Le travail bénévole, doit correspondre à leurs disponibilités

coûts

  • Tubes & Fibres : 3 Millions d'euros
  • Génie civil : 1.4 Millions d'euros
  • Coût par mètre : 8.6 € ! (8600 € le kilomètre)
Analyse des photos à partir de leur base Flickr

Quelques notes sur les photos de leurs chantiers :

Le matériel dans le coffre

Boitier d'abonné intérieur :

Boitier abonné extérieur :

Détails sur le raccordement :

Il s'agit a priori de tubes Emtelle dans lequel la fibre est soufflée

De ce qu'on peut en voir dans le Catalogue

Page 58, il s'agit d'un "Tube Bundle Connectivity – External to Internal"

tube-emtelle.jpg

Dans le sol, c'est un certain type de tube Puis cela passe à un plus petit tube qui va rentrer dans le foyer.

Traversées de mur :

Avoir une mèche assez grande !

Génie civil sans laisser de traces dans la pelouse, retourner l'herbe.. pour reboucher sans laisser de trace.

A l'intérieur d'une chambre de marque Emtelle :

On peut voir différentes choses :

  • Les tubes orange sont composés de pleins de petits tubes
  • Les petits tubes sont bouchés au scotch ou avec des bouchons

Génie civil dans le jardin, repérage du tube avec un fil vert, afin d'éviter les AlertePelleteuz

Pour travailler sur les Cassettes, un support en bois, avec une forme arrondie pour accueillir le boitier d'épissurrage extérieur

Système de soufflage de la fibre dans les tubes orange :

Voici une vidéo qui explique comment la fibre est poussée dans le tube :

  • Etape 1 : faire un espèce de bouchon avec du lubrifiant au milieu
  • Envoyer ce piston lubrificateur jusqu'a l'autre bout du tube
  • Etape 2 : Mettre la fibre entre les roues de la machine, qui va pousser la fibre jusqu'à l'autre bout : moins d'échauffement, ça glisse plus facilement.

Une chambre emtelle :

La communication est un élément important :

Un autre exemple :

Ici on voit l'importance de poser la fibre sur une bache, pour éviter d'avoir de la saleté qui se glisse dans le tube, lors du "soufflage"

Vue sur la table de fixation de la boite d'épisurage :

Autre système, l'envoi de fibre optique par soufflage dans les micro tubes :

  • on voit bien le rouleau de fibre optique au sol

Vidéo d'un forage dirigé

https://www.flickr.com/photos/b4rur...

La fibre chez l'abonné, qui arrive via un tube :

Cul de sac :)

Tube avec ses mutiple tubes fibre :

Les chambres, avec des graviers qui seront déposés sur le fond :



Pour se protéger de la pluie pendant les soudures, une nouvelle méthode :

Zoom sur un tube, multi-tubes :

Travail participatif pour rentrer chez l'abonné.. avec l'abonné :

Après

Détail sur la fibre soufflée dans son tonneau :

Une variante pour la soudure de fibre en voiture :

Soufflage d'une fibre

Détail du passage de la fibre, dans le boitier abonné

[|https://farm9.staticflickr.com/8244/8597930247_a2014577e3_o.jpg

Dérouler du tube avec une mini-pelle ?

La méthode avec tracteur :

[|https://farm9.staticflickr.com/8093/8463023634_b657e9d152_o.jpg

Le système d'accroche des boites d'épissurage peut avoir différents usages ! :)

Comment ouvrir un câble ?

Une autre technique avec une pelle, pour passer du câble en terrain meuble :

Dans l'équipement utile, le détecteur de métaux :

Il s'agit d'un RD2000 - Fiche technique

Exemple d'utilisation :

Second équipement le RD1000

Brochure

C'est un radar de sol, qui permets de détecter les tubes non métalliques

Zoom sur un tube, multi-tube

Exemple de boite de routage des tubes

Les différents types de tubes et de fibres utilisés :

  • 96 fibres
  • 8 Fibres
  • 12 fibres
  • 4 fibres
  • Une seule fibre :)

Quelques vidéos

Un test de torture du réseau

Vidéo sur une armoire de point de mutualisation :

  • C'est un peu le bordel dans les baies entre les fibres
  • Je ne vois pas d’étiquettes sur les câbles
  • 2 onduleurs stackés sous les switchs
  • On ne voit pas les switchs

Mise à jour 16 juillet 14

Un opérateur semble aussi déployer de la fibre optique à la façon B4RN !

Docker : quelques notes

Docker

  • "tout installer et long et compliqué"
  • "nous voulons les bonnes versions de chaque outil"
  • "nous ne voulons pas installer tout et n'importe quoi en étant root"

Problématique générale, connue par plein d'admins :

  • pour installer un logstash, un cassandra, un truc compliqué :


** Faut la bonne version de certains outils
** Faut plein de manips
** Et souvent à la fin, cela ne refonctionne plus

Solution à tous ces problèmes

  • Docker fournit un conteneur dans lequel tous les outils sont installés
  • Simple a démarrer / tuer / deployer selon besoins
  • Environnement identique pour tous les dev du projet

docker

  • ne fonctionne que sous linux
  • Si pas sous linux : utilise une machine vagrant
  • Machine vagrant = lenteurs : répertoires partagés lents
  • Proche d'un hyperviseur "bare metal"

installation

  • récupérer l'image
  • la lancer
  • se connecter en ssh dessus

Autres slides

  • notion de déploiement immuable
    • un déploiement qui ne change pas d'un environnement à un autre

comprendre la problématique

  • C'est celle du transport des marchandises
  • la solution passe par les conteneurs de marchandises et toute la logistique..

(En cours d'écriture.. ou la suite dans un autre billet)

Haproxy notes suite

Faire un gracefull restart

Un redémarrage, qui n'a aucun impact sur la prod :

haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)

C'est aussi ce que fait un :

/etc/init.d/haproxy reload
 
haproxy_reload()
{
       check_haproxy_config
       $HAPROXY -f "$CONFIG" -p $PIDFILE -D $EXTRAOPTS -sf $(cat $PIDFILE) \
               || return 2
       return 0
}

Note infiniband

http://www.dailymotion.com/video/x1...

La norme définit :

  • Switchs infiniband
  • routeurs
  • subnet manager
  • Application extérieure au réseau, qui définit les adresses etc..

Caractéristique Inifiband :

  • Bande passante : 56 Gb/s
    • Pourquoi 56 Gb/s c'est la capacité du Pci Express
  • Produits EDR : 100 Gb/s
  • Latence : 0.6 ms
  • réseau fiable : pas de pertes de paquet
    • Différents mécanismes pour corriger / surveiller
    • Mécanismes pour retransmettre paquets perdu
  • Efficacité de la couche transport, l'application ne s'en occupe pas. Le CPU des machines fait autre chose.
  • structures flexibles (via subnet manager)
  • subnet manager : grande simplicité

topologies

  • fast tree
  • mesh
  • drag & fly

Ce subnet manager a un rôle fondamental, il configure switchs et routes

Les plus gros réseaux ont 10, 15 000 nodes.

couche physique

  • défintion de la couche physique :
    • QDR : 40 Gb/s
    • FDR & EDR : nouveau codage 64/66

Adressage

  • dans le monde ethernet, les switchs apprennent les mac
  • subnet manager : apprends la topologie
    • tables linéaires : plus efficaces
  • VL : virtual lane (voies virtuelles) c'est une approche qui permets à diférentes sortes de trafic de recevoir différentes QoS (xx applications : xx parts de bande passante)

Mécanismes de surveillance des paquets

  • deux points connectés l'un à l'autre : chaque point connait l'état de la destination. Un paquet sera pas envoyé si le récepteur ne peut pas le recevoir.

Partition (ou VLAN)

  • Pareil qu'ethernet

Couche de liaison données

  • Sur un même lien
  • possibilité d'avoir plusieurs applications
    • Séparation possibles : I/O / admin.. pas la peine d'avoir xxx cartes réseaux
  • Deux processus infiniband communiquent via une "queue pair" envoi/réception.
  • Architecture de communication fournie par infiniband
    • des files de transport

J'ai arrêté de prendre des notes, tellement la conférencière est brouillon..

HaProxy quelques notes

Voilà déjà un certain temps que j'avais envie d'étudier HaProxy

Je pense que c'est la bonne solution pour faire du loadbalancing avec surveillance de l'état des services.

Fonctionalités de HaProx

  • Supporte le SSL
  • ipv6
  • Les sockets UNIX
  • Compression gzip/deflate
  • Dispose d'une interface CLI pour être mis à jour

Quelques chiffres sur les performances :

  • Xeon E5 of 2014 can forward data up to about 40 Gbps. A fanless 1.6 GHz Atom CPU is slightly above 1 Gbps.
  • 30000 sessions per GB of RAM.
  • Session rates around 100,000 sessions/s can be achieved on Xeon E5 systems in 2014.

fonctionnalité de synchronisation

It is possible to synchronize server entries in stick tables between several haproxy instances over TCP connections in a multi-master fashion.

exemples de configuration

  • Mode loadbalacing :

exemple de config:

listen http 127.0.0.1:8080
       mode tcp
       option tcplog
       balance roundrobin
       maxconn 10000
       server web01 127.0.0.1:80 maxconn 32
       server web02 127.0.0.1:81 maxconn 32

Maximum de 32 connexions pour les deux backends, dans mon cas un nginx local qui écoute sur les ports 80 et 81

stats en ligne de commande :

hatop -s /run/haproxy/admin.sock

Système redondant au niveau ip

Il faut utiliser un système qui fait du VRRP, keepalived. Voici un exemple : http://andyleonard.com/2011/02/01/h...

Voici le partage des tâches :

  • Keepalived s'occupe des "vip" et le fait très bien
  • haproxy : s'occupe de l'équilibrage TCP ou HTTP et il le fait très bien
    • peers est utilisé pour synchroniser les sessions entre les haproxy

tester les checks

  • httping http://127.0.0.1:8080/ -f
  • regarder les stats :
hatop -s /run/haproxy/admin.sock
  • onglet Numéro 4
  • quand on supprime le fichier de test

Rappel sur ma conf :

      option httpchk GET /test.htm
       server web01 127.0.0.1:80 maxconn 1000 check
       server web02 127.0.0.1:81 maxconn 1000 check

donc sur mon serveur nginx, je supprime :

rm test.htm

Le haproxy s'en rends compte très rapidement et le mets en state "DOWN" puis quand je remets le fichier

cp 1/test.htm .

Le serveur redeviens "UP"

Et du coté de httping : aucun DOWN !

connected to 127.0.0.1:8080 (235 bytes), seq=26405 time=63.84 ms 
- http://127.0.0.1:8080/ ping statistics - 
26406 connects, 26406 ok, 0.00% failed, time 19393ms
round-trip min/avg/max = 0.1/0.6/692.9 ms

Retour d'erreur en cas de coupure de nginx

NGINX est down (/etc/init.d/nginx stop) haproxy renvoie un :

L4CON

La doc indique :

L4CON   -> layer 1-4 connection problem, for example
                  "Connection refused" (tcp rst) or "No route to host" (icmp)

Là, c'est un vrai point en plus face à Keepalived, qui ne dit rien.. hormis des erreurs dans syslog

Présentation au FRNOG


FRNOG 22 - Willy Tarreau : HAProxy 1... par frnog

Outil

Générateur de config :

En cours d'écriture

SQL vs NOSQL (suite des notes)

Des notes, un peu en vrac

La vision selon microsoft : http://fr.slideshare.net/DecideursI...

Argumentaire contre le cloud "libre" :

  • montée en compétence longue
  • coûts élevés
  • complexité de la solution

une explication de mapreduce : explication-mapreduce.jpg

Introduction Nosql

  • Les limites des bases relationnelles :
    • Scalabilité
  • Il n'est pas possible de distribuer la charge sur plusieurs serveurs
  • La seule solution est d'avoir un serveur encore plus gros

Problématiques :

  • Les vendeurs facturent les licences au nombre de coeur
  • Le prix du matériel haut de gamme

A comparer de la tendance cloud :

  • commodity hardware : matériel pas cher, qu'on peut se permettre de voir tomber en panne sans avoir de coupure du service.
  • Mise en cluster

Définition de NoSQL :

  • Not Only SQL
  • No SQL

A débuté en 2009

  • N'utilise pas de modèle relationnel
  • Donc pas de langage SQL
  • Conçu pour foncitonner en cluster
  • Tendance à être Open Source
  • Pas de schéma, donc permets de stocker n'importe quelle donnée dans n'importe quel ligne.

Modèles de distribution des clusters :

Sharding

  • Chaque élement du cluster écrit et lit ses propres données

Bénéfices

  • Performances
  • En écriture car scaling horizontal
  • En lecture lorsque que géolocalisation des données
  • Espace disque des machines
  • Résilience partielle voire localisée

Préoccupations

  • Répartition équitable des données

Réplication maître / esclave

  • Toutes les écritures sont faites sur le maître
  • Les changements se propages aux esclaves
  • Lectures faites des esclaves ou du maître

Bénéfices Pour les applications avec beaucou de lecture :

  • performance
  • Résilience
  • Élasticité par ajout de nouveau esclaves

Préoccupations

  • Inconsistance possible en lecture (local read-write à gérer par le driver)
  • Résilience de l'écriture, le maître est un point de faiblesse : voir aussi la capacité à changer de rôle : SLAVE -> MASTER
  • Algo de vote et élection automatique du nouveau maître

Réplication peer to peer

  • Tous les noeuds écrivent et lisent les données
  • Les noeuds communiquent unquement leurs écritures

Bénéfices

  • Résilience en lecture comme en écriture
  • Elasticité par provisioning transparent
  • Performances des lectures

Préoccupations

  • inconsistances car écritures simultanées possibles
  • Performances des écritures
    • voir le quorum et versions vectors
  • Volume de données à synchroniser

Théorème CAP

« Il est impossible pour un système distribué de satisfaire plus de 2 des 3 propriétés suivantes : Cohérence, Disponibilité et Résistance au morcellement » - Eric Brewer, 2000

Cohérence Consistancy Tous les clients voient les mêmes données

1 Disponible Availability

Un nœud recevant une requête doit répondre (et non : le système est ok si panne de noeuds)

Résistance au morcellement Partition tolerance

Le système continue de fonctionner même en cas d'échec de communication entre noeuds

Différentes solutions NoSql et leur méthode de stockage :

panoram-solutions.jpg

Solutions Bases Document

  • Arbres stockant des données JSON, XML, BSON...

En cours d'écriture

logstash & collectd

  • collectd : outil de supervision pour collecter des informations sur l'état d'une machine
  • logstash : outil de collecte des logs

Exemple :

coté collectd.conf :

 /etc/collectd/collectd.conf
Hostname    "host.example.com"
LoadPlugin interface
LoadPlugin load
LoadPlugin memory
LoadPlugin network
<Plugin interface>
   Interface "wlan0"
   IgnoreSelected false
</Plugin>  
<Plugin network>
   <Server "127.0.0.1" "25826">
   </Server>
</Plugin>
/etc/init.d/collectd restart

coté logstash :

/etc/logstash/conf.d/logstash.conf

input {
 collectd {}
}
output {
 elasticsearch { host => test }
 stdout { codec => rubydebug }
}

lancer logstash :

GEM_HOME=/opt/logstash/vendor/bundle/jruby/1.9 /usr/bin/java -Djava.io.tmpdir=/var/lib/logstash -Xmx500m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Djava.awt.headless=true -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -jar /opt/logstash/vendor/jar/jruby-complete-1.7.11.jar -I/opt/logstash/lib /opt/logstash/lib/logstash/runner.rb agent -f /etc/logstash/conf.d -l /var/log/logstash/logstash.log

regarder le log :

{
          "@version" => "1",
        "@timestamp" => "2014-07-01T13:07:20.418Z",
              "host" => "host.example.com",
            "plugin" => "interface",
   "plugin_instance" => "wlan0",
     "collectd_type" => "if_packets",
                "rx" => 13409344,
                "tx" => 8561654
}

les données sont en cours de collecte

Exemple de dashboard kibana :

  • http://demo.packetbeat.com/#/dashboard/elasticsearch/Packetbeat%2520Statistics

performances postgresql

  • http://demo.packetbeat.com/#/dashboard/elasticsearch/PgSQL%20Performance

Mysql

  • http://demo.packetbeat.com/#/dashboard/elasticsearch/MySQL%20Performance

En cours d'écriture

SQL ou NOSQL ?

http://fr.slideshare.net/jnunemaker...

NOSQL :

Le web, la naissance de NOSQL

  • d'un graph très complexe en SQL
  • on passe à du JSON

Systèmes de clé / valeur :

  • memcache
  • redis
  • riak
  • voldemort
  • tokyo cabinet

Systèmes documents ;

  • mongodb
  • couchdb

Relationnel :

  • mysql
  • postgresql

Scaling the web

  • problèmes potentiels des bases de données relationnelles :
  • Matériel
    • réseau lent
    • disque dur lent
    • CPU insuffisant
    • Mémoire insuffisante

Logiciel :

  • trop de lectures
  • trop d'écritures

Scale UP Vs Scale OUT :

Scale UP :

  • plus de matériel
  • plus de cpu / mémoire etc..

Scale OUT :

  • plus de machines
  • plus de machines
  • plus de machines

Scale UP :

  • plus grosse machine
  • plus rapide
  • plus de mémoire
  • plus de CPU
  • loi de moore

Scale OUT :

  • oubliez la loi de moore
  • ajoutez des nodes
  • Master / slave
  • sharding

C'est quoi NoSQL :

Ce n'est pas une base de données relationel

Types de NoSQL :

Key Value Store :

  • non relationel
  • Pas de schéma
  • Mapper une clé (chaine) à une valeur

Exemple de Key Value :

  • redis = redis.new
  • redis.set("foo", "bar")
  • redis.get("foo")

> "bar"

http://fr.slideshare.net/Dataversit...

diskseeks.jpg

diskseeks1.jpg

logstash notes (suite)

http://fr.slideshare.net/jamtur01/y...

  • horodatage + données = log
  • Transforme toutes les données de log au format JSON

http://fr.slideshare.net/XebiaFranc...

  • Monitoring métier
  • produits achetés ?
  • Clients fidèles ?

http://fr.slideshare.net/proidea_co...

Transport format JSON :

  • Javascript Object Notation
  • description intégrée

Redis :

  • Utiliser un serveur redis, afin de pouvoir supporter de fortes charges
  • pas de filtres sur les logstash qui sont frontaux

http://fr.slideshare.net/RyanClark7...

Elasticsearch :

  • auto-indexation
  • hautement scalable
  • auto clusterisation

Bref, ça se débrouille !

  • facile a deployer

en cours d'écriture

Varnish et logstash

quelques notes :

varnishncsa -F '{"server":"%h","clientip":"%{X-Forwarded-For}i","url":"%U","queryString":"%q","status":"%s","size":"%b","userAgent":"%{User-agent}i","domain":"%{Host}i","cacheStatus":"%{Varnish:hitmiss}x","responseTime":%D}' | java -jar /etc/logstash/logstash.jar agent -e 'input { stdin { codec => line type => "varnish"} } output { redis { host => "xx.domain.co.uk" data_type => "list" key => "logstash" } }'*

http://logstash.net/docs/1.4.2/inpu...

Schéma exemple d'architecture : http://wooster.checkmy.ws/2013/12/c...

logstash-architecture.png

Faire du log sur des requêtes lentes

Exemple de conf :

Tout faire en 15 minutes :

Un logstash scalable : http://michael.bouvy.net/blog/en/ca...

Notes :

Conf qui ne fonctionne pas encore :

input {

 file {
   path => "/tmp/varnishncsa.log"
   type => varnish
 }

}

output {

 
 
 stdout { debug => true debug_format => "json"}
 elasticsearch {
   host => "127.0.0.1"
 }

}

logs varnish temps réel :

varnishncsa -F '%{VCL_Log:client}x %{VCL_Log:proto}x %{VCL_Log:authorization}x %{Bucket}o %m %{Host}i %U %b %s %{Varnish:time_firstbyte}x %{Varnish:hitmiss}x' > /tmp/varnishncsa.log

logstash : bug

logstash ne démarre pas

erreur :

LoadError: no such file to load -- i18n

solution : lancer à la main et rajouter devant :

GEM_HOME=/opt/logstash/vendor/bundle/jruby/1.9

GEM_HOME=/opt/logstash/vendor/bundle/jruby/1.9 /usr/bin/java -Djava.io.tmpdir=/var/lib/logstash -Xmx500m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Djava.awt.headless=true -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -jar /opt/logstash/vendor/jar/jruby-complete-1.7.11.jar -I/opt/logstash/lib /opt/logstash/lib/logstash/runner.rb agent -f /etc/logstash/conf.d -l /var/log/logstash/logstash.log

- page 1 de 260