Linux Attitude

Niveau :      
Résumé : quelques ordre de grandeur

Voici quelques ordre de grandeur qui vous permettront d'avoir les idées un peu plus claires sur les performances de votre système. Imaginez que le swap est 100 000 fois plus lent que la mémoire du processus ! Qu'un algorithme de création d'arbre peut être plus lent qu'un algorithme linéaire si chaque nœud de l'arbre se retrouve sur une page différente (pensez à vos centaines de malloc pour remplir un arbre) !

Notez que l'important ce sont les ordres de grandeur, vous pouvez facilement trouver des éléments qui font le double ou la moitié de ces performances.

Interprétations

Sérieusement, pas besoin de giga de swap sur votre serveur. Mettez un tout petit peu et vous monitorez dès que ca dépasse, imaginez la division par un nombre à 5 chiffres du nombre de pages vues sur votre serveur ! Pour ma part je préfère répondre à moins de requêtes par seconde et garder un serveur utilisable.

Mais sur votre station de travail vous faites ce que vous voulez, on est en général plus patient :-)

Pas de gettime à gogo dans votre code pour mesurer les perf, ça tue les perfs ...

Le réseau fait a peu près aussi bien que votre disque.

Pas de malloc à gogo pour des structures morcelées et très utilisées. faites une structure unique si vous devez en avoir beaucoup.

Le SSD c'est bien mais ca vaut pas l'accès direct au flash.

Étant donné la vitesse de compression un swap compressé peut vraiment valoir le coup.

Le cache processeur sert vraiment à quelque chose ... si on sait coder pour qu'il soit utilisé (ou laisser le compilateur faire).

Le fork c'est un peu lent, prévoyez un prefork correct sur vos applications fréquemment appelées.

Avoir beaucoup de processus n'est pas si coûteux en soi (context switch).

PS : Si vous avez des données pour compléter ce tableau, n'hésitez pas à me laisser des commentaires.

Niveau :      
Résumé : housing, server hosting, vps, web hosting

Petite fiche technique pour ne pas se perdre dans le monde de l'hébergement :

Housing

C'est le même terme en français, on dit aussi colocation, il désigne en général la fourniture de l'espace dans une armoire, du réseau et de l'électricité et c'est tout.

Pourtant c'est en général l'offre la plus chère car la plus lourde à gérer pour l'hébergeur. C'est plutôt destiné aux entreprises qui ont leur propre matériel et/ou dont l'activité sera de revendre l'accès à leur propre matériel.

Server hosting

Ou serveur dédié en français. Pratique pour une PME, ce concept permet à un sysadmin ou une petite boite d'avoir un ou des serveurs qu'elle gère entièrement, sans contraintes mais aussi sans avoir à gérer la redondance électrique ou la redondance du réseau.

On a en général une bien meilleure disponibilité et un bien meilleur débit qu'un serveur hébergé chez soi. Donc valable dès qu'on offre des services à l'extérieur. De plus on ne s'embête plus avec les matériel et ses pannes ou presque.

VPS

Ou serveur virtuel en français. C'est une machine virtuelle sur laquelle vous avez tout pouvoir (root) mais située sur une machine physique partagée avec d'autres clients.

Cela permet de faire des machines très peu chères en contrepartie d'une absence de garantie de performances.

A noter qu'OVH a sorti un produit intermédiaire entre le vps et le dédié nommé RPS. Il s'agit d'un dédié léger mais dont le disque est partagé sur le réseau.

Niveau :      
Résumé :

Aujourd'hui les disques atteignent des limites qui n'avaient pas été prévues lorsqu'on les fabriquait comme des machines à laver (notez que le premier disque tournait déjà à 3600 tours par minute.

Les disques ont d'abord été adressés au format cylindre, tête, secteur (CHS), puis au format LBA. Les différentes limites ont évolué en fonctions de la taille du bus d'adressage.

Limites

Aujourd'hui on rencontre encore plusieurs limites. Tout d'abord au niveau logiciel, les partitions qui prévoyaient un adressage linéaire sur 32 bits des secteurs trouvent une limite à 2To (2^32 * 512).

Aujourd'hui au niveau du disque lui-même, les fabricants qui stockaient les informations de redondance et de structure du disque sur chaque secteur commencent à trouver cet espace très restreint.

Aujourd'hui les disques sont tellement gros que la lecture d'un disque entier est extrêmement longue, une erreur dans un fichier et la récupération du système de fichier devient une opération très lourde.

Aujourd'hui les disques sont tellement gros que la restauration d'un disque dans un raid prends un temps énorme, au point qu'il est possible d'avoir une seconde défaillance pendant ce temps.

Aujourd'hui les disques normaux sont tellement gros qu'on utilise le même disque pour plusieurs machines.

Aujourd'hui les disques sont tellement petits qu'on en utilise plusieurs par machine.

Avec tous ces problèmes, on voit beaucoup de choses évoluer.

RAID 6+1

Les disques étant de plus en plus lents et de plus en plus gros, on est déjà passé du raid5 au raid6 pour éviter les problèmes de lenteur lorsqu'un disque manquait, on envisage d'ajouter un nouveau disque de redondance pour éviter le cas où un 2e disque grille pendant la restauration du premier.

SAN

Maintenant tout le monde a un NAS chez lui, mais les serveurs utilisent des SANs qui se partagent sur des interfaces réseau standard et plus seulement SCSI ou Fiber Channel. Le iSCSI, le AoE ainsi que d'autres protocoles permettent d'accéder à ces périphériques de façon transparente et sans matériel supplémentaire.

GPT

Les disques atteignent couramment une taille de 2To. Le format de partition actuel ne permet pas d'utiliser le disque au delà de cette taille. Il devient donc rapidement obligatoire de passer au format GPT. Ceci implique des modifications dans le bios et dans le système d'exploitation.

Secteur 4k

Les secteurs de 512 octets devenant petit, on commence à fabriquer des disques ayant des secteurs de 4ko. Cela permettra une plus grande capacité, de meilleures performances, mais implique aussi des changements au niveau du bios et de système d'exploitation (très lourd cette fois). Quelques références et solutions.

Filesystem

Toutes ces fonctionnalités nouvelles peuvent êtres prises en compte au niveau du système de fichier pour permettre des fonctionnalités sympathiques. Le snapshot fréquent voir continu, l'utilisation de plusieurs disques locaux voire distants, la vérification d'intégrité en live, la récupération d'une perte sans downtime, la possibilité d'utiliser des disques d'une taille quasiment infinie pour notre époque, l'usage d'un même filesystem par plusieurs machines ...

Tout ceci n'était qu'un aperçu qui je l'espère vous donnera envie de connaître les nouvelles technologies à venir.

Niveau :      
Résumé : Raid 10, raid 0+1, raid 5, raid 6

Lorsqu'on parle de redondance, de haute disponibilité et de disque, on parle de Raid. J'en ai déjà parlé

Voici un petit aperçu des différents types de RAID, le but est ici de trouver les qualités de chacun. Un tableau final récapitule les avantage et les inconvénients qu'il y a à choisir un type de raid donné.

Jbod

Just a bunch of disk, ce n'est pas un raid, le choix de ceux qui veulent pouvoir ajouter des disques bout à bout sans gain de performance.

Contrairement au raid 0 il a un avantage, la perte d'un disque n'empêche pas la récupération des données sur les disques restants par un outil de récupération tel que photorec. En effet, comme les disques sont simplement mis bouts à bout, la plupart des fichiers tiennent intégralement sur un seul des disques. Il est donc possible d'en récupérer le contenu après un crash.

Le jbod se fait avec du LVM sans striping ou avec le driver linear de md.

Raid 0

Le choix de ceux qui veulent des performances.

Chaque disque est découpé en bande (stripe) et les bandes sont entrelacées pour donner le disque final. Ce qui donne un gain de performance appréciable puisque les disque peuvent être lus simultanément, même pendant la lecture d'un gros fichier. Et ils peuvent être écrits simultanément pendant les écritures.

Le raid 0 peut être matériel, logiciel avec le driver md de linux ou logiciel avec LVM (avec striping)

Niveau :      
Résumé :

Maintenant que nous connaissons le processus de boot, si on examinait ce processus d'un point de vue de la sécurité !

Lorsqu'on parle de sécurité, il faut d'abord savoir dans quel cas on se positionne et de quoi on cherche à se prémunir. Ici, je considère que le système lui-même est sécurisé. Je suppose que l'attaquant est devant la machine et cherche un accès root.

On considère que chaque élément est sécurisé pour ce qui est de ses propres fonctionnalités, ce qui veut dire que si le bootloader est protégé par mot de passe, il n'y a pas de faille dans le bootloader lui-même permettant d'outrepasser ce mot de passe. Nous nous attacherons donc à chercher ce qui peut être détourné dans le flux d'exécution en entrée et en sortie de chaque élément.

Je vais commencer par la fin, du plus facile au plus difficile.

rc

Rc est lancé par init et ne prend ses paramètres que de init. Ceux-ci sont fixés en dur dans /etc/inittab. Son démarrage ne peut donc être détourné que d'une façon : par modification du contenu du disque. GoTo partition /

Parmi ces paramètres il y a le paramètre 1 qui lance rc dans le runlevel 1, ce qui dans la plupart des cas se termine par un sulogin. Ouf on est protégé par le mot de passe root.

Mais vérifiez bien, dans certains cas il se termine par un simple shell et donc réussir à passer un tel paramètre permettrait à l'attaquant un accès root à votre machine.

Pour passer 1 en paramètre GoTo init

Niveau :      
Résumé : bios, bootloader, noyau, init, rc

Je ne me souviens pas avoir fait un article complet sur le processus de boot. Il y en avait un partiel ici. En voici un !

BIOS

Le bios est le premier élément à être lancé, si on excepte l'appui sur le bouton ON et quelques autres détails. Celui-ci initialise le processeur ainsi qu'une partie du matériel, comme la carte vidéo ou le clavier.

Le bios est constitué d'une mémoire (rom ou flash) placée sur la carte mère.

Notez que quasiment tous les bios étant maintenant des flash il est possible de les mettre à jour, voire de les remplacer. Et justement un projet existe pour remplacer les bios propriétaires par des bios libres (comme Max): coreboot de son ancien nom linuxbios.

Le bios est configuré pour choisir un périphérique sur lequel booter. En général c'est le premier disque dur, mais cela peut aussi être une clé usb ou un lecteur disquette. Il est même possible de choisir au moment du boot.

Sur le périphérique en question, et à l'exception du lecteur CD qui a son protocole (el torito), le bios charge le premier secteur (512 octets), le met en RAM, et le lance.

Notez que le "BIOS" est spécifique aux PC, d'autres architectures ont des firmware EFI (Apple) ou des OpenBoot (Sun).

Bootloader

Dans ce premier secteur se trouve le bootloader (grub, lilo, silo, syslinux, mbr dos ...).

Le bootloader est découpé en plusieurs morceaux à cause de la limite des 512 octets. Sa première activité est de réussir à se charger complètement.

Celui de windows est assez simpliste, mais sous linux on en trouve avec plein de fonctionnalités sympa.

Une fois qu'il est prêt, il lit sa configuration puis choisit un périphérique et une partition où lire le noyau et éventuellement un initrd. Et enfin il passe la main au noyau en lui donnant quelques paramètres.

Niveau :      
Résumé : sensors-detect ; sensors; hddtemp; fancontrol

Sensors

Comment connaître les différentes températures à l'intérieur de votre machine ? Il y a des capteurs, donc il y a bien une information quelque part. Linux a tous les drivers nécessaires, mais pour ceux qui se sont essayé à regarder, c'est difficile de savoir qui sert à quoi. Heureusement, il y a lm-sensors pour venir à notre secours.

Pour avoir la liste de tous les capteurs disponibles sur la machine ainsi que les driver linux associés à charger, il existe une commande toute simple une fois le paquet lm-sensors installé :

$ sensors-detect

Cette commande scanne le matériel, vous pose une question ou deux et termine en vous listant les modules noyau à charger pour pouvoir obtenir les valeurs. Deux choses à faire :

# On charge le(s) module(s)
$ modprobe lemodule
# Et on automatise ça pour le prochain reboot
$ echo lemodule >> /etc/modules

Et voilà, il ne vous reste plus qu'à lire les valeurs. Pour cela, vous avez plusieurs outils :

# lecture simple des valeurs en mode texte
$ sensors 
# lecture avec interface graphique (ne marche pas chez moi)
$ xsensors

Ou les traditionnelles applet qu'on peut trouver sur gnome, kde, gkrellm, windowmaker ...