Backup , l intégration du backup sur disque

23 FÉVRIER 2010 - N°2

3

23 FÉVRIER 2010 - N°2 A new look for centralized Backup@EPFL

Lifting du service de sauvegarde centralisé de l’EPFL

Voici la nouvelle architecture de backup introduite au DIT en 2009:

l’intégration sur disque (B2D ^&). Tout d’abord un petit rappel de l’architecture précédente suivi d’un état des lieux du service et en- fin de la solution retenue avec les évolutions à court terme (2010).

Architecture précédente

L’architecture précédente, voir la figure 1, était composée de ser- veurs SUN:

z d’un master serveur (Sun Fire 280R) avec les catalogues as- sociés (unité appelée 3310 qui conserve la liste des données sauvegardées et leurs emplacements, ie sur quelles bandes !), serveur en production depuis novembre 2002;

z de trois médias serveurs (Sun Fire v240) pour les backups non

NDMP ^&, c’est à dire les sauvegardes que nous appellerons

standards, ces médias serveur ont été mis en production entre 2004 et 2005;

z un autre média serveur filer EMC-NAS dédié aux backups de type NDMP. Ce serveur est dans l’architecture de sauvegarde depuis mai 2005;

z un serveur T1000 pour faire l’in- terface avec la librairie SL8500.

Pour la partie stockage:

z une librairie SL8500 Sun/Stora- getek avec une capacité de 3000 slots depuis janvier 2007;

z huit lecteurs/drives 9940Bs, chaque média pouvant contenir 200GB non compressés, avec un débit d’écriture de 30MB/s ou 105GB/h. Ces lecteurs sont dé- diés aux backups standards (non NDMP);

z quatre lecteurs T10000B de chez SUN, chaque média pouvant contenir 1000GB non compres- sés, avec un débit d’écriture de 120MB/s ou 420GB/h. Deux de

ces lecteurs sont dédiés aux backups NDMP depuis 2007, les deux autres sont réservés aux backups du projet CADMOS ^&. Pour la partie logiciel:

z Symantec Netbackup 6.5.3.1.

Depuis 2007, les serveurs de backups et leur stockage (les lecteurs/

drives) associés sont connectés via le SAN du DIT ^&, l’intégra- tion du SAN dans l’architecture a permis le partage des lecteurs entre les serveurs de backups, d’où une meilleure utilisation des ressources. Précédemment les lecteurs étaient directement ratta- chés au serveur, il n’y avait pas de partage des lecteurs entre les serveurs.

L’ensemble de clients début 2009 était d’environ 120, pour une volumétrie de 8.5TB en moyenne par jour. La volumétrie était répartie entre les backups NDMP et les backups standards. Les clients standards sont de type Solaris, Linux, Windows, Mac et autres ¹.

Constats

Grâce à la surveillance/monitoring du service, certaines métriques nous permettent de mieux connaître le comportement de notre infrastructure. Ces métriques nous aident à prendre les décisions sur l’évolution de l’infrastructure, elles sont présentées ci-dessous.

La plupart des métriques sont disponibles pour les clients du ser- vice sur le site backup.epfl.ch.

Backup 2009-2010, l’intégration du backup sur disque

Aristide.Boisseau@epfl.ch

EPFL – Domaine IT, Coordinateur de la cellule backup et stockage

1 seer.entsupport.symantec.com/docs/325328.htm

Master server SunFire 280R Ultrasparc 900 Mhz 2GB RAM

3 media servers Sunfire v240 Ultra Sparc IIIi 1Ghz - 2GB RAM ACLS server

SunSparc T1000 1Ghz -8GB RAM

Drive T10000A 120 MB/s 500GB / tape Catalog disk array 3310

700 GB

LAN - 100/1000 Mb/s

SAN - 1/2/4 Gb/s

EMC2 filer NDMP media

server 3*2*1 Gb/s 2*1 Gb/s

2*1 Gb/s 2*1 Gb/s

3*4 Gb/s 3*4 Gb/s

3*4 Gb/s 1*1 Gb/s

Local MA B0 466

ACLS controlled SL8500 library 3200 tape slots BLUE GENE drives

4*2 Gb/s 4*2 Gb/s 2 Gb/s 2 Gb/s

NETBACKUP drives

Drive T9940B 30MB/s 200GB / tape 2*1 Gb/s

4 Gb/s 4 Gb/s

4*4 Gb/s 1 Gb/s

NETBACKUP drives

fig. 1 – architecture début 2009

Serveurs

Les serveurs du service de backup ont plusieurs années de services derrières eux (plus de six ans pour le master serveur). Avec l’aug- mentation du nombre de clients du service, les serveurs étaient de plus en plus sollicités comme le montrent les charges CPUs des figures 2, 3 et 4. De plus, SUN arrête de les vendre (product End Of Life), nous les renouvelons donc pour pouvoir absorber l’augmen- tation des demandes de services et maintenir un service pérenne.

fig. 2 – master server CPU load janvier-mars 2009

fig. 3 – média serveur 1 CPU load janvier-avril 2009

fig. 4 – média serveur 2 CPU load janvier-mai 2009

Capacités du service

Nous dissocions les backups NDMP des backups standards, ils le sont de facto, car ils utilisent des ressources différentes (types de lecteurs différents). Sur les six premiers mois de l’année 2009, le volume des backups NDMP (serveurs de fichiers EMC2, NetApp) représente environ un tiers (2.7TB) de la volumétrie globale (8.6TB) comme le montrent les figures 5 et 6.

fig. 5 – NDMP gigabytes sauvegardés

fig. 6 – volumétrie globale sauvegardée en gigabytes

Capacité librairie SL8500

Comme le montre la figure 7, la librairie SL8500 début 2009 était quasiment pleine de bandes. Pour augmenter la capacité de stoc- kage du service de backup sans modification de la librairie SL8500, le seul moyen était de remplacer les lecteurs 9940B par les lec- teurs de dernière génération avec des capacités de stockages su- périeures (1TB versus 200GB par bande). Pour la même surface au sol la capacité de stockage est 5 fois supérieure avec les nouvelles bandes utilisées par les T10000B.

En fonction du type de bandes/médias utilisé, la capacité globale du stockage disponible pour le backup évolue (dans notre cas d’un facteur 5):

Capacité librairie avec des médias pour 9940B:

3000 * 200GB = 0.58 PB ^&

Capacité librairie avec des médias pour T10000B:

3000*1TB = 2.92 PB

fig. 7 – historique capacité librairie SL8500

Capacité théorique de backup

La capacité globale des 9940Bs à sauvegarder sur une tranche de 24h est d’environ 20TB (8 lecteurs à 30MB/s en écriture).

La capacité globale des deux T10000B à sauvegarder sur une tranche de 24h est d’environ 20TB (2 lecteurs à 120MB/s en écri- ture).

Utilisation des lecteurs

Les lecteurs 9940B ont été utilisés 7 heures en moyenne par jour sur le premier semestre 2009. Le volume journalier moyen à sauve- garder est de 6TB (voir fig. 5 et 6), le débit moyen observé est donc de 31MB/s ce qui représente une bonne utilisation des lecteurs au regard de leur performance théorique d’écriture de 30MB/s.

Les deux lecteurs T10000B sont quant à eux utilisés en moyenne 15h par jour pour sauvegarder un volume de 2.7TB, soit un débit moyen de 25MB/s en regard d’un débit théorique de 120MB/s.

Les lecteurs T10000 sont donc sous-utilisés, les clients n’arrivent

pas à fournir le débit pour une utilisation optimale en écriture des lecteurs.

Bilan

z Une librairie pleine d’anciennes bandes avec un besoin tou- jours croissant de capacité pour le service de sauvegarde nous amène irrémédiablement à changer l’ensemble des lecteurs 9940B par des T10000. Nous avons vu le gain en terme de capacité au paragraphe Capacité librairie SL8500.

z Les lecteurs T10000 sont plus rapides (écriture/lecture) que les 9940B, on peut supposer qu’il en faudra moins pour assurer la sauvegarde de la volumétrie globale du service. Par contre, il faut trouver un moyen pour optimiser les débits sur ces lecteurs, on a vu qu’au paragraphe Utilisation des lecteurs ceux-ci sont sous-utilisés. La solution est d’utiliser du backup sur disque ou VTL ^& (un cache intermédiaire) pour ensuite op- timiser les débits d’écriture entre le disque et les bandes.

z Des serveurs à renouveler pour suivre l’évolution du service de sauvegarde autant en termes de capacité que de perfor- mances.

Évolution du service

Les choix sur l’évolution du service sont expliqués ci-dessous, pour les parties lecteurs, serveurs, sauvegarde sur disque et délocalisa- tion ! L’idée principale étant de simplifier si possible l’architecture, pour une administration du service plus efficace d’une part et pour un meilleur service aux utilisateurs d’autre part.

Lecteurs

Le choix des lecteurs étant quasiment imposés (librairie et lecteurs déjà existants), il nous fallait en déterminer le nombre nécessaire pour assurer un service optimal. Un nombre de quatre T10000B semblait dans un premier temps suffisant pour nos besoins, si nous étions capables de les utiliser à leur capacité maximale.

Quatre lecteurs T10000B peuvent théoriquement écrire 20TB sur 12h (on sauvegarde sur disque la nuit, on écrit sur les lecteurs le jour), ce qui est plus du double de la volumétrie journalière obser- vée sur la figure 6 ².

Serveurs

Le choix des nouveaux serveurs s’est porté sur des serveurs SUN UltraSPARC T2+. Tout d’abord pour conserver un matériel qui s’est avéré très fiable depuis 2002 (une seule panne en exploitation:

un disque). Ensuite pour l’utilisation de Solaris 10 et de ses fonc- tionnalités ZFS ^&, qui nous permettent une gestion du stockage simple, sûre donc efficace.

Nous avons profité du renouvellement des serveurs pour en dimi- nuer le nombre, nous avons réduit le nombre de médias serveur de trois à deux (moins de maintenance, plus simple à administrer).

Le master serveur (T5240) a du stockage intégré qui remplacera la baie externe (3310) utilisée pour le stockage du catalogue (un élément en moins !)³.

Voici les Les figures 8, 9 et 10 montrent l’évolution de la charge CPU sur les serveurs durant l’année 2009, on devine facilement quand ils ont été remplacés.

fig. 8 – Evolution de la charge CPU veritas en 2009

fig. 9 – Evolution de la charge CPU veritas-md1 en 2009

fig. 10 – Evolution de la charge CPU veritas-md2 en 2009

Sauvegarde intermédiaire sur disque ou VTL ?

Le choix s’est porté sur de la sauvegarde sur disque dans un pre- mier temps, et ceci, pour plusieurs raisons:

z intégration simple;

z administration aisée;

z coût inférieur à une VTL.

Les avantages de la sauvegarde sur disques sont:

z performances des lecteurs T10000B indépendantes des per- formances clients;

z meilleure utilisation des lecteurs --> diminution de leur nombre;

z restauration immédiate depuis les disques (pas d’accès aux bandes);

z administration facilitée.

Les inconvénients du backup sur disques:

z des coûts supplémentaires (on espère avoir un bon ROI ^&

avec moins de lecteurs en exploitation !) à l’achat et égale- ment en maintenance;

z des éléments supplémentaires dans l’infrastructure à gérer;

z en cas de panne d’une baie, l’impact sur le service est plus important qu’une panne d’un lecteur.

2 Quelques références sur la librairie SL8500, les lecteurs T10000B et 9940B: www.sun.com/storage/tape_storage/tape_libraries/sl8500; www.sun.com/storage/tape_storage/tape_drives/t10000b et www.sun.com/storage/tape_storage/tape_drives/t9940.

3 Descriptifs détaillés des nouveaux serveurs sur le site du fabricant: www.sun.com/servers/coolthreads/t5240/index.xml et www.sun.com/servers/coolthreads/t5120/index.xml.

Nous avons choisi deux baies de stoc- kages 6140 de SUN (www.sun.com/sto- rage/disk_systems/midrange/6140/), avec chacune 32TB de stockage net (48 disques SATA de 1TB). La protec- tion utilisée pour les baies de stoc- kage est du RAID ^&6 (6+2). Le choix de SUN pour les baies nous assure une homogénéité pour la maintenance et le support de notre infrastructure de backup, c’est à la fois un avantage (un seul intervenant en cas de problème) et un inconvénient (pas idéal pour faire jouer la concurrence).

La volumétrie permet de conserver les backups sur disques environ une semaine pour le moment, ce qui per- met dans la majorité des cas des faire les restores directement depuis les disques. En effet les demandes de res- tores sont généralement faites sur des données perdues récemment.

La gestion de la protection se fait au niveau des baies 6140 (RAID6), la ges- tion des luns ^& et de l’espace de stoc- kage associé se fait avec ZFS depuis les serveurs via un pool ZFS (B2D1 dans l’exemple ci-contre).

L’ajout de nouvelle capacité dans les pools ZFS se fait à chaud sans inter- ruption de service. Il suffit d’ajouter le nouveau lun via une simple com- mande:

zpool add B2D1

c5t600A0B800048F4DA000009B14A4B8BD0d0

L’architecture de ZFS est basée sur 128 bits, voici quelques limites théoriques associées à ZFS:

The 128-bit architecture also means that there are no practical limits on the number of files, directories, and so on. Here are some theoretical limits that might, if you can conceive of the scope, knock your socks off:

• 2⁴⁸ snapshots in any file system

• 2⁴⁸ files in any individual file system

• 16 exabyte file systems

• 16 exabyte files

• 16 exabyte attributes

• 3x10²³ petabyte storage pools

• 2⁴⁸ attributes for a file

• 2⁴⁸ files in a directory

• 2⁶⁴ devices in a storage pool

• 2⁶⁴ storage pools per system

• 2⁶⁴ file systems per storage pool

Le choix de l’ OS a été pris d’une part pour sa fiabilité, mais égale- ment pour la partie ZFS, qui nous permet de gérer le stockage de manière simple, sûre donc très efficace J ⁴.

Finalement, chaque 6140 est dédié à un seul média serveur, il n’y pas de partage du stockage entre les médias serveurs (à l’inverse des lecteurs qui peuvent être utilisés par n’importe quel serveur).

La raison est simple, les licences Netbackup pour la gestion du partage du stockage se font au volume (par TB) et non par baie.

In fine le coût de ces licences et leurs maintenances seraient pro- hibitifs en exploitation. La gestion des disques appelée standards de Netbackup (tel qu’utilisé dans notre architecture via ZFS) n’en- traîne aucun coût de licence supplémentaire J.

4 Voici deux liens sur la gestion ZFS: www.sun.com/bigadmin/features/articles/zfs_part1.scalable.jsp et www.sun.com/bigadmin/features/articles/zfs_part2_ease.jsp.

4

/s

NETBACKUP drives NETBACKUP drives

Drive T10000B 120 MB/s 1 TB per tape

LAN - 100/1000 Mb/s

SAN - 1/2/4 Gb/s

4 Gb/s 4 Gb/s

4 Gb/s 4 Gb/s

4 Gb/s 4 Gb/s

4*4 Gb/s

2*4 Gb/s 2*4 Gb/s

3*4 Gb/s 3*4 Gb/s

3*2*1 Gb/s 1*1 Gb/s

2*1 Gb/s 2*1 Gb/s

2*1 Gb/s

1 Gb/s

1 Gb/s 1 Gb/s

Local BM 9137

Media server T5120 SunSparc T2 8 cores 1.2 Ghz - 16 GB RAM Media server T5120

SunSparc T2 8 cores 1.2 Ghz - 16 GB RAM

MAsterserver T5240 SunSparc T2+ 2*6 cores

1.2 Ghz - 32GB RAM 1TB embedded catalog

ACLS server SunSparc T1000 1 Ghz - 8GB RAM

ACLS controlled SL8500 library 3200 tape slots BLUE GENE drives

SUN 6140 Disk array - 4 GB 48*1 TB SATA-II SUN 6140 Disk array - 4 GB

48*1 TB SATA-II

EMC2 filer NDMP media

server

Local MA B0 466

fig. 11 – architecture générale 2009

# zpool list

NAME SIZE USED AVAIL CAP HEALTH ALTROOT B2D1 32.6T 28.8T 3.87T 88% ONLINE - sys 136G 31.5G 105G 23% ONLINE - DIT-EX[root@veritas-md1]# zpool status pool: B2D1

state: ONLINE

scrub: none requested config:

NAME STATE READ WRITE CKSUM B2D1 ONLINE 0 0 0 c5t600A0B800048F476000007EB49D23F94d0 ONLINE 0 0 0 c5t600A0B800048F4DA000008CB49D23F9Ed0 ONLINE 0 0 0 c5t600A0B800048F4DA000009B14A4B8BD0d0 ONLINE 0 0 0 c5t600A0B800048F4DA000009AD4A4B8B78d0 ONLINE 0 0 0 c5t600A0B800048F4DA000009A94A4B88B4d0 ONLINE 0 0 0 c5t600A0B800048F476000009404A4B9B76d0 ONLINE 0 0 0 errors: No known data errors

Architecture 2010 – Backup sur disque La figure 11 montre l’architecture avec les nouveaux serveurs, les baies de disques et l’ensemble des lecteurs au nombre de quatre pour le service de sauvegarde et deux lecteurs pour la sauvegarde du projet CADMOS (remplace le Bluegene/L).

Les serveurs ont été remplacés au printemps 2009 (comme le montrent les figures 8, 9 et 10) ainsi que l’ajout des deux nou- veaux lecteurs T10000B, les baies de disques ont été mises en pro- duction en juillet.

Le nombre de composants a diminué de 30% passant de 20 (ser- veurs, lecteurs, librairie et 3310) à 14, l’administration du service en est donc simplifiée.

Serveurs

Le master serveur intègre le stockage des catalogues via ZFS.

Chaque média serveur est connecté à sa baie de stockage via deux cartes fibres (HBA ^&) de 4Gb/s chacune, les lecteurs sont quant à eux accédés via un seul HBA. Un média serveur utilise au plus deux lecteurs en même temps.

Les sauvegardes NDMP se font également sur disques via les mé- dias serveurs et non plus directement sur les lecteurs T10000B.

Backup sur disque

Les sauvegardes se faisant sur disques, elles ne sont plus pénali- sées par les erreurs d’écritures sur bandes.

Les demandes de restauration de données sont pour la plupart effectuées depuis les disques (en moyenne une semaine de sauve- garde conservée sur les disques), dans ce cas de figure il n’y a pas d’attente pour l’obtention des ressources (disque en lieu et place du lecteur et des bandes).

La duplication des données se fait dans la journée en utilisant de manière optimale les lecteurs (optimisation des performances d’écritures indépendantes des clients J). En cas de panne d’une baie 6140 on perd une nuit de backups, c’est un point négatif de l’introduction du backup sur disque. La probabilité est cependant faible (ZFS sur du RAID 6).

Sur les figures 12 et 13 on voit que les performances d’écritures sur les lecteurs T10000B sont atteintes (deux lecteurs en parallèle au plus par média serveur): plus de 300MB/sec en pointe (supé- rieur à 2*120MB/s J).

fig. 12 – performances décembre 09 HBA veritas-md1 --> lecteurs

fig. 13 – performances décembre 09 HBA veritas-md2 --> lecteurs

Futur proche Netbackup 7.0

Netbackup 7.0 est annoncé pour début 2010, une mise à jour de notre infrastructure n’est pas envisagée avant l’été ! Les nouvelles fonctionnalités sont en particulier l’intégration de la déduplica- tion et des techniques de sauvegarde telles que VCB ^& pour l’in- tégration des outils de backup de VMWare dans Netbackup (déjà existantes dans Netbackup 6.5). La mise en place de Netbackup 7.0 fera l’objet d’un article dans le Flash informatique.

Changement de SLA

Une évolution du SLA ^& sera proposée courant 2010, pour une mise en place en 2011. Il s’agira de diminuer la rétention des données sauvegardées pour réduire la volumétrie conservée sur bandes et ainsi libérer des ressources.

Déménagement en BM

L’ensemble de l’infrastructure de sauvegarde (librairie, lecteurs, disques et serveurs) sera hébergé dans un nouveau local dédié dans le bâtiment BM. Cette séparation des données (source et sauvegarde) permettra de renforcer la sécurité et la pérennité

GLOSSAIRE

&

B2D (backup to disk): sauvegarde sur disque CADMOS (Center for Advanced Modeling

Science): initiative des universités de Genève, Lausanne et de l’EPFL dans le domaine des ordinateurs à haute puissance de calcul et de leur utilisation. www.cadmos.org

HBA (Host Bus Adapter): une carte d’extension qui permet de connecter un système hôte à un bus externe réseau de stockage.

lun (Logical Unit Number): identifiant d’unité logique, c’est-à-dire pointeur vers un espace de stockage.

NDMP (Network Data Management Protocol):

protocole de communication ouvert utilisé pour la sauvegarde des équipements stockage en réseau NAS. Il doit permettre, en environne- ment hétérogène, une meilleure communica- tion entre équipements de stockage et logiciels de sauvegardes.

PB (PetaByte): 1 pétabyte est équivalent à 1000 térabytes ou 1 million de gigabytes.

RAID (Redundant Array of Inexpensive Disks):

matrice redondante de disques indépendants.

ROI (Return on Investment): terme économique qui signifie retour sur investissement.

SAN du DIT: service de stockage du Domaine IT mis à la disposition des Facultés et des services centraux de l’EPFL. sanas.epfl.ch.

SLA (Service Level Agreement): document qui définit la qualité de service requise entre un prestataire et un client.

VCB (VMware Consolidated Backup): interface de backup VMware.

VTL (Virtual Tape Library): technologie de virtua- listation du système de stockage.

ZFS (Zettabyte File System): système de fichier open source, produit par Sun Microsystems.

du service. La librairie, les bandes et les lecteurs ont été déplacés au mois de no- vembre 2009, les serveurs et les disques seront déplacés du MA au BM en début 2010.

Une allée froide confinée a été installée pour héberger les serveurs dans le nouveau local de backup, ce confine- ment permet de mieux ré- guler la gestion de l’air froid et ainsi permet de faire des économies d’énergies J. Le principe est simple: on pulse l’air froid dans une zone confinée (au plus près des serveurs) et non plus dans le

volume total de la salle. On peut voir l’allée froide composée de quatre racks pour l’instant sur les figures 14 et 15.

Conclusion

Depuis plus d’une année des changements majeurs ont été appor- tés au service de backup, apportant une gestion plus simple d’un point de vue administratif et une plus grande flexibilité du côté client (restore immédiat depuis les disques).

Les prochaines évolutions du service se focaliseront sur une meilleure gestion de la volumétrie avec très certainement l’intro- duction de la déduplication (coté client et/ou serveurs/disques) avec la mise en place de Netbackup 7, sans oublier la maîtrise de l’énergie et des coûts ! n

SCRT organized for the third year a contest of Ethical Hacking Insomni’hack which took place in Geneva on January 22nd.

La société SCRT a organisé pour la troisième année consécutive un concours d’Ethical Hacking Insomni’hack qui s’est déroulé à Genève le 22 janvier dernier.

La troisième édition d’Insomni’hack s’est tenue vendredi 22 Jan- vier 2010 dans les locaux de l’HEPIA (Haute Ecole du Paysage, d’Ingénierie et d’Architecture de Genève).

Peu connu du grand public, le hacking éthique est une spécialité informatique qui consiste à attaquer le système d’une entreprise avec son consentement et sur sa propre demande, ceci dans le but de détecter les failles du système qui pourraient être exploitées par des personnes malintentionnées.

Plus d’une centaine de participants se sont affrontés de 18h à 1h du matin au travers d’une série de plusieurs épreuves en sé- curité informatique, spécialement créées par la société SCRT. Les participants étaient originaires de plusieurs pays francophones et européens (France, Suisse, Espagne, Canada, ...) et âgés de 16 à 40 ans environ.

Bien que les concurrents ne soient pas parvenus au bout de toutes les épreuves que comptait le concours, le vainqueur, un Français, a néanmoins réalisé le score très honorable d’environ 5300 points.

Cette prestation lui a valu de remporter les lots destinés au ga- gnant, composés entre autres d’un firewall Fortinet et d’une li- cence Kaspersky (antivirus).

En marge des épreuves de hacking à proprement parler, les nom- breuses personnes, venues en tant que visiteurs, n’ont pas été lais- sées en simples spectateurs.

En effet, des épreuves de lockpicking - discipline ayant pour but l’ouverture de serrures sans la clé – leur ont permis de participer activement à l’événement.

Tout s’est déroulé sans accroc et la bonne humeur était au ren- dez-vous.

Les nombreux journalistes ayant fait le déplacement afin d’assou- vir la curiosité éveillée par cette discipline peu commune peu- vent en attester. Les échos des participants ont, en tout cas, été unanimes: tous ont passé un excellent moment et ont apprécié l’initiative.

Vous trouverez prochainement sur notre site (www.scrt.ch) quelques corrigés des défis ainsi que des photos et vidéos de la soirée. n

Insomni'hack – concours de hacking éthique

Paul Such, directeur SCRT

Actualités

fig. 14 – entrée allée froide

fig. 15 – arrière allée froide