Effectuez vos sauvegardes avec Bareos

Magazine
Marque
GNU/Linux Magazine
Numéro
212
Mois de parution
février 2018
Spécialité(s)


Résumé

La récente vague de ransomwares [1] a placé sous les projecteurs un aspect aussi ingrat qu’essentiel du travail d’administrateur système : les sauvegardes. En effet, quand tous les pare-feux ont été traversé, les antivirus déjoués et les privilèges escaladés, seule la sauvegarde peut nous sauver !


Body

1. Introduction à la sauvegarde

Pour bien comprendre quel type de sauvegarde nous allons aborder dans cet article, il convient de clarifier quelques notions :

  • La réplication de fichiers : ce type de technologie est utilisée dans les architectures dites à haute disponibilité (ou HA pour High Availibility). Un service en haute disponibilité sous-entend qu’il s’appuie sur plusieurs ressources et que l’indisponibilité d’une des ressources ne l’interrompt pas.
  • Les services de snapshots : un snapshot est un état du système de fichiers à un instant ‘t’. En pratique, cela consiste à conserver une copie de chaque bloc de donnée modifié depuis cet instant ‘t’ pour être capable de revenir à cet état à tout moment. La profondeur temporelle du snapshot est limitée par l’espace qui lui est alloué.
  • La synchronisation : une synchronisation est une réplication qui intègre la notion de « hors ligne ». Un client peut être connecté de façon intermittente à une ressource. Le processus de synchronisation détecte la disponibilité de la ressource distante et envoie les nouvelles données. Les systèmes de synchronisation évolués tentent de gérer les conflits générés par la multiplicité de clients pour la même ressource (clients lourds, services web, smartphones, etc.).
  • Une action volontaire de l’utilisateur : un disque externe connecté sur la machine avec un rsync dans un cron. C’est mieux que rien...

Tous ces mécanismes concernent ce que l’on appelle la donnée chaude, c’est-à-dire que la donnée est immédiatement accessible, car rapidement consultée.

Dans cet article, je vais aborder les données froides. Les données sont archivées et consultées uniquement en cas de remédiation à un sinistre physique qui n’a pu être conjuré ni par la réplication, ni par les snapshots. Dans le monde du libre, il y a un certain nombre d’outils pour faire de la sauvegarde. Les plus significatifs sont BackupPC, Bacula et Bareos.

J’ai écarté BackupPC, car je dois aussi sauvegarder du Windows. BackupPC s’appuie massivement sur rsync et je ne voulais pas installer la couche Cygwin.

Bacula et Bareos sont strictement identiques d’un point de vue fonctionnel. Et pour cause, Bareos est un fork de Bacula. Ce fork est principalement motivé par des problèmes de licence [2].

1.1 Généralités sur les logiciels de sauvegarde

Pour quasiment tous les logiciels de sauvegarde de la terre, il existe trois types de sauvegardes : incrémentales, différentielles et complètes. La complète passe l’intégralité du jeu de fichiers définit par la politique dans la sauvegarde. La différentielle passe les fichiers modifiés depuis la dernière complète. L’incrémentale passe les fichiers modifiés depuis la dernière sauvegarde (qu’elle soit complète ou incrémentale). On notera que la différentielle peut sauvegarder plusieurs fois les mêmes états de fichiers. En contrepartie, la remontée de ceux-ci lors d’une restauration est grandement simplifiée.

Justement, à propos de la restauration, chaque logiciel de sauvegarde intègre un catalogue qui contient toutes les informations pour restaurer des fichiers sans avoir à parcourir séquentiellement tous les médias de stockage (ce qui est encore plus dommage quand on fait de la sauvegarde sur disque à accès aléatoire). Ce catalogue se présente généralement sous la forme d’une base de données. Nous allons utiliser MySQL pour gérer le catalogue de notre instance Bareos. Je considère dans la suite de l’article que nous avons un serveur MySQL en état de marche.

1.2 Installation

L’installation de Bareos est très simple dans la mesure où l’équipe de développement propose des paquets tout faits pour (quasiment) toutes les distributions. Nous allons l’installer sous Debian Jessie. En premier lieu, il faut ajouter les dépôts Bareos aux sources d’apt :

# cat /etc/apt/sources.list.d/bareos.list

deb http://download.bareos.org/bareos/release/latest/Debian_8.0 /

Et récupérer la clé publique de ce nouveau dépôt :

# wget -q http://download.bareos.org/bareos/release/latest/Debian_8.0/Release.key -O- | apt-key add -

Ensuite, on passe à l’installation proprement dite de Bareos :

# apt-get update

# apt-get install bareos bareos-database-mysql bareos-webui

Enfin, il faut préparer la base de données du catalogue de sauvegarde. Nous avons trois scripts à disposition qui ne sont que des surcouches de la commande mysql. Il faut les exécuter dans la séquence suivante :

# /usr/lib/bareos/scripts/create_bareos_database

# /usr/lib/bareos/scripts/make_bareos_tables

# /usr/lib/bareos/scripts/grant_bareos_privileges

On crée un utilisateur bareos dans MySQL qui sera utilisé par le logiciel pour accéder au catalogue :

# mysql -u root -p

mysql> grant all privileges on bareos.* to ‘bareos’@’localhost’ identified by ‘dbpass’ ;

Il ne reste plus qu’à lancer les démons :

# systemctl start bareos-dir

# systemctl start bareos-fd

# systemctl start bareos-sd

Nous disposons d’une installation fonctionnelle.

2. Architecture de Bareos

L’architecture de Bareos est exactement la même que celle de Bacula déjà présentée dans GMLF [3]. Pour mémoire, Bareos se divise en trois démons bareos-dir, bareos-sd et bareos-fd, respectivement « Director », « Storage daemon » et « File daemon ». Nous allons illustrer le fonctionnement des trois démons en appliquant une politique de sauvegarde. Cette politique consiste à sauvegarder le contenu d’un serveur en faisant une totale le premier de chaque mois et une incrémentale tous les jours. Nous conservons une profondeur de catalogue de deux mois pour chaque type de sauvegarde. Toute la configuration est localisée dans le répertoire /etc/bareos. Commençons par la partie la plus indigeste, la configuration de bareos-dir.

Avant de se lancer dans l’explication des fichiers de configuration, il convient de tracer à gros traits les interactions entre les différents démons. Le démon bareos-dir s’exécute sur le serveur de sauvegarde. Le démon bareos-sd sur le serveur de stockage (dans notre article, bareos-sd et bareos-dir tournent sur la même machine). Enfin, bareos-sd tourne sur le client à sauvegarder. Le programme bareos-dir est le chef d’orchestre de Bareos. C’est lui qui est en charge de la planification des travaux de sauvegarde et les initie. Il a également la connaissance des fichiers à sauvegarder pour chaque machine ainsi que des ressources à utiliser pour le stockage. Il contacte donc le démon bareos-fd pour lui indiquer les fichiers à sauvegarder et lui remettre un cookie d’authentification. À la réception de la requête, le service bareos-fd utilise le cookie pour s’authentifier auprès du démon bareos-sd et lui envoie les données à sauvegarder. Enfin, bacula-sd écrit les données sur le média physique (disques, bandes, etc.) indiqué par bareos-dir.

echanges

 

Fig. 1 : Interactions entre les démons.

2.1 bareos-dir

Deux programmes interagissent de façon interactive avec bareos-dir : bconsole et la webui. Comme leurs noms l’indiquent, bconsole est en mode texte et webui en mode web. L’accès à bareos-dir se configure dans le fichier bareos-dir.d/director/bareos-dir.conf :

Director {

  Name = bareos-dir

  QueryFile = "/usr/lib/bareos/scripts/query.sql"

  Maximum Concurrent Jobs = 10

  Password = "XX_PassDirectorBareos-dir_XX"

  Messages = Daemon

  Auditing = yes

  Heartbeat Interval = 120 }

À ce stade, il faut lever une petite ambiguïté qui m’a causé soucis lors de la prise en main de Bareos. La section Director n’est pas liée au démon bareos-dir (qu’on peut aussi trouver nommé Director dans certaines documentations, ce qui est piégeux). La section Director dans les fichiers sert à définir les modalités d’accès aux services Bareos à savoir bareos-dir, bareos-fd et bareos-sd. Cette section contient un mot de passe qui est un secret partagé entre le service et les clients ayant besoin d’y accéder. Il contient également les paramètres TLS et différentes autres options d’accès. Les services de Bareos peuvent être tour à tour clients et serveurs les uns des autres.

Une fois bareos-dir accessible, il faut implémenter la planification de la sauvegarde. Il faut ajouter un fichier dans le répertoire bareos-dir.d/schedule avec la configuration suivante :

Schedule {

        Name = "DFSCycle"

        Run = Level=Full Pool=DFSFull 1st sun at 01:00

        Run = Level=Incremental Pool=DFSIncremental 2nd-5th sun at 01:00

        Run = Level=Incremental Pool=DFSIncremental mon-sat at 1:00

}

Ce fichier définit trois travaux, respectivement par ordre des lignes :

  • une sauvegarde totale tous les premiers dimanche du mois à 1h ;
  • une incrémentale les autres dimanches (2nd-5th) à 1h ;
  • une incrémentale tous les soirs du lundi au samedi à 1h.

Ce qui est intéressant ici c’est que chaque travail est lié à un pool. Un pool est un ensemble de ressources physiques un peu abstraites sur lesquelles vont se faire les sauvegardes. Nous en avons deux, DFSFull et DFSIncremental. Je donne l’exemple de la configuration de DFSFull.

La configuration de notre pool se trouve dans bareos-dir.d/pool/DFSFull.conf :

Pool {

        Name = "DFSFull"

        Pool Type = Backup

        Use Volume Once = yes

        AutoPrune = yes

        Recycle = yes

        Maximum Volume Bytes = 200G

        Volume Retention = 2 months

        Label Format = DFSFull-

        Maximum Volumes = 30 }

D’après le fichier, notre ensemble de ressources est composé de 30 volumes (Maximum Volumes) de 200GB (Maximum Volume Bytes). À ce stade de la configuration, on ne sait pas s'il s’agit de cassettes type LTO de 200GB, de fichiers de 200GB etc. Ces volumes seront physiquement personnifiés plus tard. Il est également indiqué que les volumes seront automatiquement labellisés sous la forme DFSFull-XX. Dans les logiciels de sauvegarde, la labellisation des volumes sert à les identifier au niveau du catalogue pour savoir quoi (les fichiers) se trouve où (le label). Les volumes sont automatiquement purgés (AutoPrune = yes) de la base de données catalogue au bout de deux mois (Volume Retention = 2 months) et marqués comme recyclables (Recycle = yes). La question suivante est : mais qu’est-ce qu’on va sauvegarder ? C’est ici que nous allons définir les ensembles de fichiers à sauvegarder sur nos clients.

Notre lot de fichiers à sauvegarder est défini dans le fichier DFSAll.conf du répertoire bareos-dir.d/fileset/ :

FileSet {

  Name = "DFSAll"

  Enable VSS = yes

  Include {

    Options {

      Signature = MD5

      Drive Type = fixed

      IgnoreCase = yes

      WildFile = "[A-Z]:/pagefile.sys"

      WildDir = "[A-Z]:/RECYCLER"

      [...]

      Exclude = yes

    }

    File = "D:/DFS"

  }}

Les plus observateurs auront remarqué qu’il s’agit de sauvegarder un client Windows. La première chose à faire est d’activer le VSS (Volume Shadow copy Service) pour que le système de fichiers soit dans un état stable lors de la copie d’un fichier. Ensuite, on définit des expressions régulières de fichiers (WildFile) à ne pas sauvegarder (Exclude = yes). Enfin, on donne le chemin du répertoire à sauvegarder (File = "D:/DFS").

Le lien avec le démon bareos-sd est fait par le fichier NFSStorage.conf que nous avons créé dans bareos-dir.d/storage :

Storage {

  Name = NFSStorage

  Address = fqdn_bareos-sd

  Password = "MDP_du_Director_de_bareos-sd"

  Device = NFSMount

  Media Type = File }

Ce fichier nous indique l’emplacement du démon bareos-sd (Address) ainsi que le secret pour y accéder (Password). Il spécifie également le type de média (Media Type) ainsi que son nom (Device). Ce nom fait du sens au niveau de bacula-sd pour décrire l’emplacement physique des volumes de sauvegarde (définis pour mémoire dans le fichier DFSFull.conf).

Il reste à définir les paramètres de connexion au client sur la machine à sauvegarder. On les retrouve dans le répertoire bareos-dir.d/client. Il faut y ajouter un fichier avec le contenu suivant :

Client {

  Name = cc-ad2-fd

  Address = fqdn_client_a_sauvegarder

  Password = "MDP_du_Director_de_bareos-fd"

  Heartbeat Interval = 120 }

À l’instar de la connexion au démon bareos-sd, il faut définir l’adresse du client (Address) et le mot de passe pour s’authentifier auprès du Director du bareos-fd du client (Password). Ouf ! Il nous reste la dernière partie, celle qui fait le lien entre toutes ces configurations pour faire un travail de sauvegarde (job).

Un travail est défini dans deux répertoires : bareos-dir.d/job et bareos-dir.d/jobdefs. La relation entre les deux est que chaque fichier du répertoire job correspond à un travail réel à effectuer sur un client tandis que le répertoire jobdefs contient des fichiers de templates. Ces templates sont inclus dans la définition des travaux de job un peu à la manière des headers en C. Commençons par voir le contenu d’un fichier du répertoire job :

Job {

  Name = "backup-cc-ad2-fd"

  JobDefs = "DFSJobDef"

  Client = "cc-ad2-fd"

  Pool = DFSFull

  Incremental Backup Pool = DFSIncremental

  Full Backup Pool = DFSFull }

Les pièces commencent à s’imbriquer. Ce fichier fait l’association entre le client à sauvegarder (Client) et le pool à utiliser pour les sauvegardes incrémentales (Incremental Backup Pool) et complètes (Full Backup Pool). On peut aussi y voir l’inclusion d’un jobdefs (JobDefs). Allons en examiner le contenu dans le répertoire jobdefs :

JobDefs {

  Name = "DFSJobDef"

  Type = Backup

  Client = cc-ad2-fd

  FileSet = "DFSAll"

  Schedule = "DFSCycle"

  Storage = NFSStorage

  Messages = Standard }

Ici, on fait le lien entre le lot de fichiers à sauvegarder sur le client (FileSet), la planification du job (Schedule) et le stockage à utiliser (Storage). Les deux autres démons sont infiniment plus simples !

conf_files

 

Fig. 2 : Relations de dépendances entre les fichiers de configuration.

2.2 bareos-sd

La configuration du démon bareos-sd se compose de deux parties : une pour définir les paramètres de son Director et une autre pour définir le(s) stockage(s) physique(s) (cf. l’attribut Device des fichiers contenus dans la section Storage de bareos-dir). Voyons la configuration du Director qui se trouve dans les fichiers situés dans le répertoire bareos-sd.d/director :

Director {

  Name = bareos-dir

  Password = "MDP_du_Director_de_bareos-sd" }

Nous avons juste un nom et un mot de passe. Ce mot de passe est utilisé par bareos-dir pour se connecter à bareos-sd (cf. l’attribut Password des fichiers contenus dans la section Storage de bareos-dir). Pour la seconde partie, la configuration se fait dans le répertoire bareos-sd.d/device :

Device {

  Name = "NFSMount"

  Media Type = File

  Archive Device = /nfs/bareos/backup

  LabelMedia = yes

  Random Access = yes

  AutomaticMount = yes

  RemovableMedia = no

  AlwaysOpen = no }

C’est la dernière brique côté serveur ! Nous avons un type de média (Media Type) qui nous dit que les volumes correspondent à des fichiers situés dans /nfs/bareos/backup (Archive Device). En conséquence, l’accès est aléatoire (Random Access = yes) et non séquentiel comme avec des bandes. Les autres paramètres sont assez explicites.

2.3 bareos-fd

C’est presque le bout du tunnel. La configuration du client se divise en deux grandes sections. La première est, sans surprises, le Director qui permet à bareos-dir de se connecter à bareos-fd pour initier le travail de sauvegarde. La seconde définit les paramètres de configurations du démon bacula-fd. Commençons par le Director, la configuration est stockée dans le répertoire bareos-fd.d/director :

Director {

  Name = bareos-dir

  Password = "MDP_du_Director_de_bareos-fd" }

On retrouve le classique nom accompagné du mot de passe permettant à bareos-dir de se connecter (cf. l’attribut Password des fichiers contenus dans la section Clientde bareos-dir). La seconde partie de la configuration se trouve dans bareos-fd.d/client :

Client {

  Name = cc-ad2-fd

  Maximum Concurrent Jobs = 20 }

2.4 Configuration du TLS

Le TLS se configure de façon assez classique sur Bareos. Il existe une documentation de grande qualité sur Internet qui couvre ce point [4] sur Bacula, mais elle est transposable à Bareos. Je vous conseille de la suivre scrupuleusement, car elle détaille une à une les connexions à sécuriser : de Bconsole à Bareos-dir, de Bareos-dir à Bareos-fd, de Bareos-dir à Bareos-fd et enfin, de Bareos-fd à Bareos-sd. D’autres documentations préconisent l’utilisation de stunnel. Cette solution peut être particulièrement pratique si on a Bareos-dir et Bareos-sd sur la même machine (donc pas besoin de TLS) et quelques Bareos-fd éparses.

3. Management de Bareos

3.1 Bconsole

La console Bareos est utilisée par l’administrateur pour interagir avec le processus bareos-dir afin de lancer des jobs, restaurer des fichiers, explorer des archives, visionner le catalogue, etc. Cette console se configure de façon extrêmement simple via un fichier bconsole.conf :

Director {

  Name = bareos-dir

  address = localhost

  Password = "XX_PassDirectorBareos-dir_XX" }

Ensuite, on peut invoquer la console et remonter l’état du bareos-dir :

# bconsole

Connecting to Director localhost:9101

1000 OK: bareos-dir Version: 16.2.4 (01 July 2016)

Enter a period to cancel a command.

*status

Status available for:

     1: Director

     2: Storage

     3: Client

     4: Scheduler

     5: All

Select daemon type for status (1-5): 5

[...]

Ceci nous renvoie l’état de l’infrastructure Bareos ; ce rapport est très complet.

3.2 webui

Le package Debian fournit une configuration type pour l’interface web. Il suffit de l’activer :

# a2enconf bareos-webui

Ensuite, on passe par bconsole pour créer un utilisateur administrateur de la sauvegarde :

# bconsole

Connecting to Director localhost:9101

1000 OK: bareos-dir Version: 16.2.4 (01 July 2016)

Enter a period to cancel a command.

* configure add console name=admin password=secret profile=webui-admin

Le profil webui-admin de l’utilisateur admin est consultable dans le fichier /etc/bareos/bareos-dir.d/profile/webui-admin.conf. Vous pouvez maintenant vous connecter sur http://<fqdn_bareos_serveur>/bareos-webui.

4. Troubleshooting Bareos

Lors de notre installation de Bareos, nous avons eu quelques soucis avec le pare-feu du site. Lorsque bareos-fd doit sauvegarder un volume de données, il commence par l’analyser pour générer les enregistrements à ajouter au catalogue. Or, cette phase peut durer un certain temps. Durant cette phase, la connexion TCP avec le director est toujours maintenue (pour mémoire, la configuration du catalogue se fait au niveau de bareos-dir), mais aucune donnée ne transite. Au bout d’un certain délai de garde, le pare-feu met fin unilatéralement à la connexion TCP entraînant l’échec de la sauvegarde. Bareos intègre un mécanisme de heartbeat, c’est-à-dire qu’un paquet vide est envoyé à intervalle régulier pour maintenir la connexion active du point de vue du pare-feu. Il faut ajouter une directive dans la configuration du client au niveau de bareos-dir :

Client {

  Name = cc-ad2-fd

  [...]

  Heartbeat Interval = 120 }

Toutes les deux minutes (120 secondes), un paquet vide est envoyé pour maintenir la connexion active.

Nous avons également eu un second souci plus vicieux. Avec de grosses sauvegardes (environ 2 Tio) depuis un bacula-fd, la sauvegarde continuait de planter suite à des soucis de connexion réseau. Après quelques (longues) recherches sur les forums de Bareos, il semblerait que certains drivers de carte réseau sous Windows supporteraient mal les heartbeats (comme certains anciens chipsets réseau NVIDIA). La solution dans ce cas est de se rabattre sur les TCP Keepalives. Dans ce cas, ce n’est plus le logiciel bareos-fd qui forge un paquet heartbeat, mais c’est le noyau qui indique à la socket d’envoyer un paquet TCP à intervalle régulier. Nous avons donc aligné le délai des TCP Keepalives sur celui des heartbeats. Pour ce faire, il faut modifier une variable du noyau via un sysctl :

# sysctl net.ipv4.tcp_keepalive_time=120

Conclusion

Bareos est donc un logiciel performant, tout à fait fonctionnel et utilisable quasiment « out-of-the-box ». Cependant, à une époque de forte décentralisation de l’informatique vers des infrastructures en nuage, il convient de se poser des questions sur l’avenir de telles solutions. À terme, la sauvegarde pourrait se résumer à envoyer des fichiers vers du stockage central versionné de telle façon que les utilisateurs pourront restaurer leurs fichiers sans intervention de l’administrateur.

Références

[1] « Une attaque informatique de portée mondiale crée la panique » : http://www.lemonde.fr/pixels/article/2017/05/12/des-hopitaux-anglais-perturbes-par-un-rancongiciel_5127034_4408996.html

[2] « Why have you started a fork from Bacula.org ? » : https://www.bareos.org/en/faq/why_fork.html

[3] MOUREY S., « Bacula : le vampire qui m’a sauvé la vie »GNU/Linux Magazine n°145, janvier 2012 : https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-145/Bacula-le-vampire-qui-m-a-sauve-la-vie

[4] Documentation Bacula/TLS : https://www.devco.net/pubwiki/Bacula/TLS/

 



Article rédigé par

Par le(s) même(s) auteur(s)

Intégration d’ownCloud pour servir un partage de fichiers existant

Magazine
Marque
Linux Pratique
Numéro
136
Mois de parution
mars 2023
Spécialité(s)
Résumé

Le logiciel libre ownCloud est une solution de partage et de stockage des fichiers en mode web. Avec la profusion des plateformes commerciales de ce type (Google Drive, iCloud, Dropbox, etc.), l’accès web aux fichiers est devenu le nouveau standard. Dans cet article, nous allons explorer une méthode pour interfacer cette méthode d’accès aux fichiers avec un serveur NFS (Network File System) existant.

Équilibrage de charge avec IPVS

Magazine
Marque
Linux Pratique
HS n°
Numéro
55
Mois de parution
octobre 2022
Spécialité(s)
Résumé

IP Virtual Server (IPVS) est un équilibreur de charge agissant au niveau 4 du modèle OSI. Il est implémenté sous forme d’un module noyau s’appuyant sur le framework Netfilter, ce qui le rend efficace sur l’équilibrage des services par rapport à leurs ports TCP/UDP, mais totalement agnostique aux protocoles applicatifs transportés (LDAP, HTTP, etc.).

Libre-service de machines virtuelles avec OpenNebula

Magazine
Marque
Linux Pratique
Numéro
130
Mois de parution
mars 2022
Spécialité(s)
Résumé

Dans un article précédent, nous avons mis en place une infrastructure OpenNebula basique [1]. Nous allons maintenant configurer cette plateforme pour proposer aux utilisateurs un guichet de libre-service de machines virtuelles. L’idée est que les utilisateurs puissent créer eux-mêmes leurs machines virtuelles.

Les derniers articles Premiums

Les derniers articles Premium

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Le combo gagnant de la virtualisation : QEMU et KVM

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

C’est un fait : la virtualisation est partout ! Que ce soit pour la flexibilité des systèmes ou bien leur sécurité, l’adoption de la virtualisation augmente dans toutes les organisations depuis des années. Dans cet article, nous allons nous focaliser sur deux technologies : QEMU et KVM. En combinant les deux, il est possible de créer des environnements de virtualisation très robustes.

Les listes de lecture

9 article(s) - ajoutée le 01/07/2020
Vous désirez apprendre le langage Python, mais ne savez pas trop par où commencer ? Cette liste de lecture vous permettra de faire vos premiers pas en découvrant l'écosystème de Python et en écrivant de petits scripts.
11 article(s) - ajoutée le 01/07/2020
La base de tout programme effectuant une tâche un tant soit peu complexe est un algorithme, une méthode permettant de manipuler des données pour obtenir un résultat attendu. Dans cette liste, vous pourrez découvrir quelques spécimens d'algorithmes.
10 article(s) - ajoutée le 01/07/2020
À quoi bon se targuer de posséder des pétaoctets de données si l'on est incapable d'analyser ces dernières ? Cette liste vous aidera à "faire parler" vos données.
Voir les 125 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous