Pensées Libres dans un Monde Binaire
find . -name '*.orig' -print
Permet de trouver tous les fichiers portant l’extension .orig dans le répertoire courant et dans tous les sous-répertoires et les affiche sur la sortie standard.
Pour supprimer directement les fichiers trouvés, on pourra utiliser:
find . -name '*.orig' -exec rm -f {} ';'
La suite de mon étude concernait le processus de sharding. Comme pour la réplication, les informations proviennent cette fois du guide sur le sharding.
Le sharding divise la donnée et la distribue sur plusieurs machines, aussi appelé shard et résout ainsi le problème de scaling horizontal. Un cluster est constitué de shard, serveur de configuration et mongos. Le sharding réduit la quantité de donnée que chaque serveur doit stocker, ainsi que le nombre d’opérations à effectuer.
Sharded cluster = shards + query routers (mongos) + config servers
Stock la donnée.
En production, pour des questions de haute disponibilité et de consistence des données, chaque shard est un replica set et le cluster est constitué de deux shards ou plus.
Sert d’interface avec l’application cliente et dirige les opérations vers le shard approprié. Un cluster peut contenir plusieurs routeurs pour distribuer la charge.
En production, un mongos ou plus.
Les curseurs et d’autres ressources étant spécifique à une instance de mongos, chaque client doit interagir avec seulement un mongos.
Stock les métadatas du cluster.
Contient un mapping entre les données du cluster et les shards (Quelle donnée se trouve sur quel shard). En production, un cluster possède exactement 3 config servers.
Si un ou deux serveurs de configuration deviennent indisponible, les métadatas du cluster passe en lecture seule jusqu’à ce que les trois serveurs soient à nouveau disponible. Il est toujours possible de lire et d’écrire sur les shards mais aucune migration et aucun découpage n’aura lieu sur les chunks.
Les sauvegardes de ces serveurs sont critiques.
Si le nom ou l’adresse qu’un cluster utilise pour se connecter à un serveur de configuration change, il est nécessaire de redémarrer tous les mongod et les mongos! D’où l’utilité des CNAMEs pour identifier les serveurs de configuration.
Chaque serveur doit être sur une machine séparée.
Le partitionnement s’effectue en utilisant une clé de sharding (sharding key).
Soit un champ indexé ou champ indexé composé existant dans tous les documents de la collection. MongoDB divise la shard key en morceaux (chunks) et les distribue de manière égale entre les shards. La division de la clé s’effectue soit avec un range based partitioning ou un hash based partitioning.
Pour sélectionner une shard key, déterminer les champs communément inclut dans les requêtes pour une application précise et déterminer quelles opérations demandent le plus de performance.
L’index sur la shard key ne peut pas être un multikey index.
Séparation des données en plusieurs intervalles. Deux documents avec une clé de sharding proche ont de grandes chances d’être dans le même chunk. Néanmoins, il peut en résulter une distribution inégale des données sur les shards. Plus efficace en cas de requêtes sur des intervalles. Le router peut déterminé plus facilement vers quels shards diriger la requête.
MongoDB calcule un hash de la valeur du champ et utilise ces hashs pour créer les chunks. Deux documents avec une clé de sharding proche ont très peu de chance d’être dans le même chunk. Cela permet de s’assurer d’une distribution plus aléatoire des données au sein du cluster et assure une distribution régulière des données sur les shards. Une requête sur un intervalle à de grande chance de s’adresser à tous les shards.
Mongo dispose de mécanismes pour éviter qu’un shard devienne trop grand: splitting et le balancer.
Lorsqu’un chunk devient trop grand, mongo le divise en deux.
Ceci n’affecte pas les données ou les shards.
Permet de migrer des chunks. Lorsque la distribution des données devient irrégulière, le balancer va migrer des chunks du shard avec le plus grande nombre de chunks à celui qui en possède le moins. Les données sont retirés du shard d’origine après une migration totale et réussie des données.
Cette semaine, j’ai eu l’occasion de commencer à étudier le fonctionnement de la réplication et du sharding avec MongoDB. Voici diverses informations provenant du guide sur la réplication.
La réplication consiste à écrire la donnée sur plusieurs serveurs et répond ainsi au problématique de haute disponibilité et de redondance des données. Elle permet, dans certains cas, d’augmenter les capacités en lecture. Un replica set peut avoir jusqu’à 12 membres dont 7 voteront à la fois. Pour disposer de plus de 12 instances, il est nécessaire de passer à la réplication maître-esclave.
L’architecture standard pour un replica set en production se compose de trois membres. Si l’application se connecte à plusieurs replica set, chacun doit avoir un nom différent. Les membres s’envoient des ping toutes les 2 secondes.
Replica Set: Groupe de mongod disposant des mêmes (~~) données.
On distingue deux types principaux de mongod dans un replica set: les primaires et les secondaires.
Il est unique et reçoit toutes les opérations d’écriture. Tous les changements sont conservés dans son oplog. Une élection d’un nouveau mongod primaire à lieux, si l’actuel ne communique avec aucun membre du replica set pendant 10s.
Récupère le oplog et applique les opérations sur son jeu de données. En cas d’indisponibilité du primaire, un mongod secondaire sera élu à sa place.
Mongod secondaire qui ne peut pas devenir primaire et ne peut déclencher d’élections. Permet de s’assurer que seul les membres qui en ont les capacités deviendront primaire (distribution géographique, hardware). Il est conseillé de s’assurer que le datacenter principal contient les votants et les membres éligibles.
Invisible pour les applications clientes. Sont toujours des membres à priorité 0, ne peuvent devenir primaire mais peuvent voter. En cluster, mongos n’interagit pas avec les membres cachés.
Reflète un état retardé de l’état du groupe.
Requis:
* Doit être un membre à priorité 0
* Devrait être un membre caché
Le délai doit être plus petit que la capacité de oplog. Cette fonctionnalité est utile pour pouvoir appliquer un rollback (retour en arrière) en cas d’erreur humaine.
Sa fonction est de voter en cas d’élection d’un mongod primaire et permet d’obtenir une majorité en cas d’un nombre pair de membres.
Important: Ne pas ajouter d’arbitre sur les machines hébergeant déjà un primaire ou un secondaire.
Déployer un nombre impair de membres pour s’assurer qu’un primaire pourra toujours être élu. Ajouter un arbitre si besoin.
Tolérance aux fautes: Correspond au nombre de membres auquel on soustrait la majorité requise pour élire un nouveau mongod primaire.
Au moins un membre à priorité 0 dans un autre datacenter. Garder une majorité de membre au même endroit.
Le sharding est souvent une meilleur stratégie pour augmenter les capacités en lecture et en écriture.
* primary
* primaryPreferred
* secondary
* secondaryPreferred
* nearest
Seul primary permet d’être sûr d’avoir des données totalement à jour.
Utiliser readPref() dans mongo shell pour accéder aux préférences.
Découvert dans le film The River Why adapté du roman du même nom de David James Duncan: Run River par Jon Swift.
Run, run river.
Carry me to my home in the ocean,
Carry me awayI know I have a home
Somewhere far and removed
Like the stars that make you feel
Like you got friends.Stars will make you feel like you got friends.
Follow the empty valley
Past the hills
To the marshes of the estuary,
Calm and peaceful river.In the light of the moon
With the river I do run
In the hope that one day
I will dive
Beneath the ocean,And that this river will forever run.
La migration de nos différents services s’effectue progressivement. Après WordPress, c’est au tour de notre système de gestion de code de changer de serveur et d’évoluer par la même occasion. Jusqu’à présent, nous utilisions Gitolite. Celui-ci fonctionne plutôt bien, une fois qu’on a trouvé les bonnes configurations. Pour une utilisation personnelle sous GNU/Linux, aucun problème, mais pour inviter d’autres contributeurs ce n’est pas toujours très simple. Entre la génération des clefs, la mise en place des bons fichiers de configuration sous Windows et l’obligation de gérer à la main les autorisations et créations de dépôts, j’ai décidé de passer à quelque chose de plus conséquent: Gitlab.
Les avantages sont nombreux: interface facilitant la gestion des dépôts et accessible à tous les utilisateurs, gestion fine du nombre de dépôts maximum pour chaque utilisateur, la création de dépôts n’est pas limité à l’administrateur et surtout, la possibilité de cloner un dépôt directement via http. Autant d’avantages qui m’ont incité à tenter l’installation de la bête.
La mise en place se déroule sans réels difficultés grâce à un guide d’installation pas à pas. Chaque étape est décrite en détails et toutes les commandes sont commentées, bref la navigation dans ce guide s’effectue sans écueils.
Le guide se termine par la configuration de Nginx pour permettre aux utilisateurs d’accéder au service. Si comme moi, vous utilisez plutôt Apache, pas de panique, des fichiers de configuration pour Apache sont également disponible. Pas grand chose à dire sur ce point là, à part de ne pas oublier d’activer les modules listés au début des fichiers via a2enmod.
La dernière étape, consiste à faire fonctionner la connexion sécurisée à tous les niveaux. Quelques recherches reste à faire de ce côté là pour s’assurer que git accepte mon certificat auto-signé. Des paramètres à modifier dans gitlab-shell entre autre.
Nous sommes maintenant près pour l’étape finale, pusher du code et mettre à disposition notre gitlab pour les amis, connaissances et autres!