Info16.fr

Le blog de B@rtounet

Archives 2011

#Gnu/Linux

Montée en charge d'un serveur Apache et DOS,DDOS

Comme chacun sait il existe en général deux types d'attaque par deni de service. les DOS et les DDOS Comme le dit bien Wikipedia: Un déni de service est une situation où un serveur informatique est incapable de répondre aux requêtes de ses clients. Un serveur informatique (par exemple un serveur Web) doit traiter plusieurs requêtes dans un court laps de temps. Lorsque le serveur est incapable de traiter toutes les requêtes qu'il reçoit, il y a déni de service. (DOS) Une attaque par déni de service distribuée (en anglais, Distributed Denial of Service attack ou DDoS attack) est une attaque par déni de service dans laquelle le serveur cible est attaqué par plusieurs ordinateurs simultanément. Pour ma part je ne m'étais jamais trop interessé à la monté en charge de mon serveur apache, pensant que mon site peu visité ne pouvait pas faire l'objet d'attaque. Mais c'est en voulant tester un outil de montée en charge tels que siege, que je me suis rendu compte qu'il était très simple de mettre à genoux un serveur peu sécurisé... Pour commencer tester la tenue en charge de notre serveur Apache avec siège. 1. Installation Après avoir récupéré le code source sur le site officiel, entrez les commandes suivante :
tar zxvf siege-latest.tar.gz cd siege ./configure make make install
2. Utilisation La première étape consiste à créer le fichier de configuration. Pour cela, il suffit de lancer la commande siege.config, dans son terminal. Ensuite, on pourra tester son serveur web avec quelque chose comme çà :
siege -d1 -r300 -c100 http://ip_du_serveur_a_tester/
Ici les options signifie : -c : nombre d'utilisateurs -r : nombre de connexion par chaque utilisateur -d : délai en seconde de sleep Ainsi, en lançant siege avec de tels paramètres, je simule la connexion de 100 utilisateurs, exécutant chacun 300 requêtes, espacé de une seconde. Ce qui fait à peu près 30 000 requêtes. Et là c'est le drame...
root@sd-15226:~# siege -d1 -r300 -c100 http://forum.info16.fr ** SIEGE 2.69 ** Preparing 100 concurrent users for battle. The server is now under siege... HTTP/1.1 200 2.79 secs: 6295 bytes ==> / HTTP/1.1 200 2.88 secs: 6296 bytes ==> / HTTP/1.1 200 2.89 secs: 6296 bytes ==> / HTTP/1.1 200 2.89 secs: 6296 bytes ==> / HTTP/1.1 200 2.90 secs: 6296 bytes ==> / HTTP/1.1 200 2.92 secs: 6296 bytes ==> / HTTP/1.1 200 2.93 secs: 6296 bytes ==> / HTTP/1.1 200 2.94 secs: 6296 bytes ==> / HTTP/1.1 200 2.95 secs: 6296 bytes ==> / HTTP/1.1 200 2.96 secs: 6296 bytes ==> / HTTP/1.1 200 3.57 secs: 6296 bytes ==> / HTTP/1.1 200 5.78 secs: 6296 bytes ==> / HTTP/1.1 200 6.59 secs: 6296 bytes ==> / HTTP/1.1 200 9.24 secs: 6296 bytes ==> / HTTP/1.1 200 9.31 secs: 6296 bytes ==> / HTTP/1.1 200 9.42 secs: 6296 bytes ==> / HTTP/1.1 200 9.46 secs: 6296 bytes ==> / HTTP/1.1 200 9.61 secs: 6296 bytes ==> / HTTP/1.1 200 9.61 secs: 6296 bytes ==> / HTTP/1.1 200 9.67 secs: 6296 bytes ==> / HTTP/1.1 200 9.73 secs: 6296 bytes ==> / HTTP/1.1 200 9.73 secs: 6296 bytes ==> / HTTP/1.1 200 9.93 secs: 6296 bytes ==> / HTTP/1.1 200 9.99 secs: 6295 bytes ==> / HTTP/1.1 200 10.17 secs: 6296 bytes ==> / HTTP/1.1 200 10.37 secs: 6295 bytes ==> / HTTP/1.1 200 10.68 secs: 6296 bytes ==> / HTTP/1.1 200 11.94 secs: 6296 bytes ==> / HTTP/1.1 200 12.88 secs: 6296 bytes ==> / HTTP/1.1 200 14.44 secs: 6296 bytes ==> / HTTP/1.1 200 14.82 secs: 6295 bytes ==> / HTTP/1.1 200 14.86 secs: 6296 bytes ==> / HTTP/1.1 200 15.05 secs: 6297 bytes ==> / HTTP/1.1 200 15.49 secs: 6297 bytes ==> / HTTP/1.1 200 15.88 secs: 6297 bytes ==> / HTTP/1.1 200 16.09 secs: 6297 bytes ==> / HTTP/1.1 200 18.04 secs: 6297 bytes ==> / HTTP/1.1 200 18.67 secs: 6297 bytes ==> / HTTP/1.1 200 19.87 secs: 6297 bytes ==> / HTTP/1.1 200 20.20 secs: 6297 bytes ==> / HTTP/1.1 200 20.92 secs: 6297 bytes ==> / HTTP/1.1 200 21.39 secs: 6297 bytes ==> / HTTP/1.1 200 21.42 secs: 6297 bytes ==> / HTTP/1.1 200 21.42 secs: 6297 bytes ==> / HTTP/1.1 200 22.94 secs: 6297 bytes ==> / HTTP/1.1 200 23.00 secs: 6297 bytes ==> / HTTP/1.1 200 23.35 secs: 6297 bytes ==> / HTTP/1.1 200 22.79 secs: 6297 bytes ==> / HTTP/1.1 200 23.74 secs: 6297 bytes ==> / HTTP/1.1 200 23.82 secs: 6297 bytes ==> / HTTP/1.1 200 23.88 secs: 6296 bytes ==> / HTTP/1.1 200 24.14 secs: 6297 bytes ==> / HTTP/1.1 200 24.72 secs: 6297 bytes ==> / HTTP/1.1 200 24.87 secs: 6296 bytes ==> / HTTP/1.1 200 24.92 secs: 6297 bytes ==> / HTTP/1.1 200 25.38 secs: 6297 bytes ==> / HTTP/1.1 200 25.43 secs: 6297 bytes ==> / HTTP/1.1 200 25.44 secs: 6297 bytes ==> / HTTP/1.1 200 25.45 secs: 6297 bytes ==> / HTTP/1.1 200 25.55 secs: 6297 bytes ==> / HTTP/1.1 200 25.79 secs: 6297 bytes ==> / HTTP/1.1 200 25.80 secs: 6297 bytes ==> / HTTP/1.1 200 25.91 secs: 6297 bytes ==> / HTTP/1.1 200 26.13 secs: 6297 bytes ==> / HTTP/1.1 200 26.30 secs: 6296 bytes ==> / HTTP/1.1 200 26.57 secs: 6296 bytes ==> / HTTP/1.1 200 27.67 secs: 6297 bytes ==> / HTTP/1.1 200 27.68 secs: 6297 bytes ==> / HTTP/1.1 200 28.52 secs: 6296 bytes ==> / HTTP/1.1 200 28.50 secs: 6297 bytes ==> / HTTP/1.1 200 28.55 secs: 6297 bytes ==> / HTTP/1.1 200 28.89 secs: 6297 bytes ==> / warning: socket: 1831987536 select timed out: Connection timed out warning: socket: 1748060496 select timed out: Connection timed out warning: socket: 1664133456 select timed out: Connection timed out warning: socket: 1605384528 select timed out: Connection timed out warning: socket: 1471101264 select timed out: Connection timed out warning: socket: 1303247184 select timed out: Connection timed out warning: socket: 1538242896 select timed out: Connection timed out warning: socket: 1236105552 select timed out: Connection timed out warning: socket: 1437530448 select timed out: Connection timed out warning: socket: 1403959632 select timed out: Connection timed out warning: socket: 1454315856 select timed out: Connection timed out warning: socket: 1840380240 select timed out: Connection timed out warning: socket: 1706096976 select timed out: Connection timed out warning: socket: 1185749328 select timed out: Connection timed out
En quelques secondes, mon serveur était down... impossible d'acceder au site, impossible aussi de se connecter en ssh... seul la réponse au ping était encore fonctionnelle. et là ca commence à faire peur.. en fait n'importe quel serveur peut etre saturé, par le moindre petit malin... Cette situation n'est pas tolérable, on ne peut pas laisser un serveur ainsi... après avoir longuement cherché et réfléchi sur un moyen de contrer ce probleme... je suis tombé sur un module d'apache des plus interessant: le mod_evasive :permet de détecter les floods et les tentatives de déni de service (DOS). Ce module renvoie des erreurs HTTP 403 lorsque le seuil de sollicitation du serveur apache par IP a été dépassé. c'est la solution. Le bandit à force de connexion répétée aura un joli placard erreur 403 et sera blacklisté un moment. 1- Télécharger le mod_evasive sur le site officiel http://www.zdziarski.com/projects/mod_evasive/ 2- Installation Nous allons utiliser l'outil apxs d'apache (apxs is a tool for building and installing extension modules for the Apache HyperText Transfer Protocol (HTTP) server) En effet c'est un outil qui permet d'installer proprement un module dans apache De base je n'avais pas la commande apxs
apt-get install apache2-threaded-dev
tar xvfz mod_evasive_1.10.1.tar.gz cd mod_evasive /usr/bin/apxs2 -i -a -c mod_evasive20.c #Module pour apache2
il faut à présent paramétrer le fichier apache2.conf. ( apxs est censé le faire, mais je pense qu'il cherche un httpd.conf qui n'est pas présent sur une distribution Ubuntu) voiçi les ligne à rajouter dans le fichier de conf d'apache.
LoadModule evasive20_module /usr/lib/apache2/modules/mod_evasive20.so DOSHashTableSize 3097 DOSPageCount 2 DOSSiteCount 50 DOSPageInterval 1 DOSSiteInterval 1 DOSBlockingPeriod 10 DOSWhitelist 127.0.0.* DOSEmailNotify admin@votredomaine.fr DOSSystemCommand "/bin/echo %s >> /var/log/apache2/evasive/evasive.log && /bin/date >> /var/log/apache2/evasive/evasive.log" DOSLogDir "/var/log/evasive"
Explications : DOSSiteCount : Le nombre maximal de requêtes qu'une adresse IP source peut réaliser sur le même enfant pendant une unité de temps sans être ajoutée à la liste noire. DOSSiteInterval : L'unité de temps (en secondes) évoquée dans la directive DOSSiteCount. La valeur par défaut est d'une seconde. DOSPageCount : Le nombre maximal de requêtes qu'une adresse IP source peut réaliser sur la même ressource (même URL) pendant une unité de temps sans être ajoutée à la liste noire. DOSPageInterval : L'unité de temps évoquée dans la directive DOSPageCount. DOSBlockingPeriod : Désigne la durée pendant laquelle tous les accès des adresses IP en liste noire seront refusés et recevront une erreur 403. Par défaut, cette durée est de 10 secondes. DOSEmailNotify : Précise une adresse email à laquelle envoyer un courriel lorsqu'une adresse IP est ajoutée en liste noire. (Attention de bien positionner MAILER dans les sources du module pour utiliser cette directive). DOSSystemCommand : Une commande à appeler pour, par exemple, ajouter l'adresse en liste noire sur un routeur. DOSWhiteList : Spécifie une adresse IP à ne jamais positionner en liste noire. Il est courant de positionner cette option à 127.0.0.* pour éviter de bloquer nos éventuels propres accès récursifs ou autres robots de référencement. En production, cette option ne devrait jamais être utilisée pour désigner un réseau d'utilisateurs humains légitimes : les mécanismes internes du module garantissent que le trafic légitime ne sera pas bloqué. Cette directive peut être positionnée plusieurs fois avec divers arguments, ceux-ci seront cumulés dans la configuration. (cf system-linux.eu) redemarrer apache
/etc/init.d.apache2 restart
Vous pouvez verifier tout de meme dans votre server-info que le module est bien chargé. Dernier petit test sur un de mes forums...
root@sd-15226:~# siege -d1 -r300 -c100 http://forum.info16.fr ** SIEGE 2.69 ** Preparing 100 concurrent users for battle. The server is now under siege... HTTP/1.1 200 0.16 secs: 5178 bytes ==> / HTTP/1.1 200 0.19 secs: 5178 bytes ==> / HTTP/1.1 200 0.19 secs: 5178 bytes ==> / HTTP/1.1 200 0.20 secs: 5178 bytes ==> / HTTP/1.1 200 0.21 secs: 5178 bytes ==> / HTTP/1.1 200 0.20 secs: 5178 bytes ==> / HTTP/1.1 200 0.20 secs: 5178 bytes ==> / HTTP/1.1 200 0.20 secs: 5178 bytes ==> / HTTP/1.1 200 0.29 secs: 5178 bytes ==> / HTTP/1.1 200 0.31 secs: 5178 bytes ==> / HTTP/1.1 200 0.37 secs: 5178 bytes ==> / HTTP/1.1 200 0.36 secs: 5178 bytes ==> / HTTP/1.1 200 0.37 secs: 5178 bytes ==> / HTTP/1.1 200 0.37 secs: 5178 bytes ==> / HTTP/1.1 200 0.37 secs: 5178 bytes ==> / HTTP/1.1 200 0.37 secs: 5178 bytes ==> / HTTP/1.1 200 0.38 secs: 5178 bytes ==> / HTTP/1.1 200 0.37 secs: 5178 bytes ==> / HTTP/1.1 403 0.36 secs: 351 bytes ==> / HTTP/1.1 403 0.36 secs: 351 bytes ==> / HTTP/1.1 403 0.36 secs: 351 bytes ==> / HTTP/1.1 403 0.36 secs: 351 bytes ==> / HTTP/1.1 403 0.36 secs: 351 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 200 0.37 secs: 5178 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 403 0.36 secs: 351 bytes ==> / HTTP/1.1 403 0.36 secs: 351 bytes ==> / HTTP/1.1 403 0.36 secs: 351 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 403 0.34 secs: 351 bytes ==> / HTTP/1.1 403 0.34 secs: 351 bytes ==> / HTTP/1.1 403 0.34 secs: 351 bytes ==> / HTTP/1.1 403 0.34 secs: 351 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 403 0.35 secs: 351 bytes ==> / HTTP/1.1 403 0.34 secs: 351 bytes ==> / HTTP/1.1 403 0.34 secs: 351 bytes ==> / HTTP/1.1 403 0.34 secs: 351 bytes ==> / HTTP/1.1 403 0.34 secs: 351 bytes ==> / HTTP/1.1 403 0.34 secs: 351 bytes ==> / HTTP/1.1 403 0.23 secs: 351 bytes ==> /
on remarque bien qu départ la réponse 200 de apache qui stipule que tout va bien, mais quand le nombres de connexions dépasse le taux définit par le module evasive on obtient une erreur 403. l'ip est balclistée durant un temps défini.
27 juillet 2011 Aucun commentaire

#Gnu/Linux

Mise en place d'un forum en cluster ( equilibrage de charge, LVM2 + DRBD + OCFS2)

Il y avait un moment que j'avais pas écris un petit billet. J'en profiste pour faire un petit mémo sur la mise en place d'un forum en cluster sur 2 serveurs dédiés type Dédibox. je dresse rapidement le tableau. Etant beta-testeur Dedibox, j'ai la chance de disposer de pas mal de serveurs dédiés de tests. Je me suis donc amusé à installé un Forum PunBB sur un cluster Actif/Actif répliqué par DRBD, et permettant les écritures concurentes grace au systeme de fichier cluster OCFS2. Un schéma vaut mieux qu'un grand discours.

Comme vous pouvez le constater, je suis parti sur le principe que pour redonder un forum, tel que punbb il faut redonder /var/www et /var/lib/mysql. Il y a pas mal de moyen pour redonder un block device, j'ai otper pour DRBD DRBD (Distributed Replicated Block Device) est un outil qui permet de synchroniser (par réplication) des périphériques de stockage (disque dur, partition, volume logique, etc.) entre deux ordinateurs via le réseau. Cette synchronisation se fait : en temps réel : elle se fait à la volée, pendant que les données sont modifiées de manière transparente : les applications, qui enregistrent leurs données sur le périphérique de stockage répliqué, le font sans même savoir qu'il s'agit d'une unité de stockage spéciale. de manière synchrone ou asynchrone : en fonctionnement synchrone, l'écriture est déclarée terminée lorsque les données sont écrites localement ET que la synchronisation est terminée. En fonctionnement asynchrone, l'écriture est déclarée terminée lorsque les données sont écrites localement (sur le serveur primaire et pas sur le serveur de réplique) uniquement. (cf ubuntu.fr) Plantons le tableau. Je suis parti de deux dédibox XL (raid0 pour le stockage) Mon partitionement:

Node1= Disk /dev/md0: 131 MB, 131530752 bytes (/boot) Disk /dev/md1: 42.9 GB, 42935779328 bytes (/)(raid0) Disk /dev/md2: 952.6 GB, 952684642304 bytes (vg0) (raid0) Node2= Disk /dev/md0: 131 MB, 131530752 bytes (/boot) Disk /dev/md1: 42.9 GB, 42935779328 bytes (/)(raid0) Disk /dev/md2: 952.6 GB, 952684642304 bytes (vg0) (raid0) /// On peut déjà apprécier l'éfficacité de Raid logiciel sous linux sur /dev/md2 /// Disk /dev/md2: 952.6 GB, 952684642304 bytes root@node1:~# dd if=/dev/md2 of=/dev/zero bs=1M iflag=direct 1111+0 records in 1110+0 records out 1163919360 bytes (1,2 GB) copied, 6,55167 s, 178 MB/s

Ca peut aller. Je suis parti d'une distribution Ubuntu 8.04 LTS 64bit kernel 2.6.24-24-server sur les 2 noeuds. - Création des LVM.

root@node1:~# apt-get install lvm2

verifier bien que le module dm_mod est chargé, sinon chargez le

dm_mod 78200 7 dm_mirror,dm_snapshot
root@node1:~# pvcreate /dev/md2
root@node1:~# lvcreate -L2G -nlv0 vg0 Logical volume "lv0" created
root@node1:~# lvcreate -L2G -nlv1 vg0 Logical volume "lv1" created

nos deux Logcial volume sont crées. destinés à contenir respectivement drbd0 et drbd1 soit /var/www et /var/lib/mysql Creer la même arborescence lv sur les 2 noeuds.

  • Installation de DRBD

Afin que l'installation de DRBD se passe bien, il faut vérifier quelques petits prérequis. Tout d'abord avoir les outils de compilation.

root@node1:~# apt-get install build-essential

Vérifier aussi d'avoir les sources de votre kernel ou du moins les header.

root@node1:~#apt-get install kernel-headers-$(uname -r) root@node1:~#apt-get install flex

Télécharger les sources de drbd sur le site http://oss.linbit.com/drbd

root@node1:/usr/src# tar xvfz drbd-8.3.1.tar.gz
root@node1:/usr/src# cd drbd-8.3.1 root@node1:/usr/src/drbd-8.3.1# make clean all

Véirifier que tout se compile bien. Installer maintenant DRBD

root@node1:/usr/src#make install -j4 root@node1:/usr/src#make install-tools -j4

attaquons nous au fichier de configuration de drbd situé dans /etc/drbd.conf

common { protocol C; startup { #become-primary-on both; wfc-timeout 30; degr-wfc-timeout 30; } disk { on-io-error detach; no-disk-flushes; no-md-flushes; no-disk-barrier; no-disk-drain; } net { max-buffers 16384; max-epoch-size 16384; unplug-watermark 128; sndbuf-size 8M; ko-count 6; allow-two-primaries; after-sb-0pri discard-zero-changes; after-sb-1pri violently-as0p; after-sb-2pri violently-as0p; rr-conflict violently; } syncer { rate 100M; al-extents 1801; verify-alg crc32c; } } resource r0 { on node1 { device /dev/drbd0; disk /dev/vg0/lv0; address 88.191.84.35:7789; meta-disk internal; } on node2 { device /dev/drbd0; disk /dev/vg0/lv0; address 88.191.84.36:7789; meta-disk internal; } } resource r1 { on node1 { device /dev/drbd1; disk /dev/vg0/lv1; address 88.191.84.35:7790; meta-disk internal; } on node2 { device /dev/drbd1; disk /dev/vg0/lv1; address 88.191.84.36:7790; meta-disk internal; } }

Pareil sur le node2

root@node2#drbdadm create-md r0 r1
root@node2#drbdadm up r0 r1

Puis nous synchronisons les ressources. Sur le node 1 nous lançons

root@node1#drbdadm -- --overwrite-data-of-peer primary r0 r1

On peut alors voir les ressources en cours de synchronisation.

Every 1,0s: cat /proc/drbd version: 8.3.1 (api:88/proto:86-89) GIT-hash: fd40f4a8f9104941537d1afc8521e584a6d3003c build by root@sd-15181, 2009-06-21 20:22:50 0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r---- ns:3157114 nr:98131 dw:1082377 dr:2373543 al:226 bm:133 lo:0 pe:1464 ua:998 ap:1 ep:1 wo:n oos:2027040 [>....................] sync'ed: 3.6% (2027040/2097052)K finish: 0:05:07 speed: 6,452 (5,832) K/sec 1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r---- ns:2640518 nr:125231 dw:593569 dr:5326403 al:92 bm:133 lo:0 pe:1472 ua:1006 ap:1 ep:1 wo:n oos:2027760 [>....................] sync'ed: 3.4% (2027760/2097052)K finish: 0:05:07 speed: 6,448 (5,772) K/sec

On peut remarquer qu'entre les 2 dedibox la synchronisation se fait 11Mo/s on sature le lien 100Mb/s ( rien ne nous empeche de limiter ce débit dans le drbd.conf)

  • Passons maintenant à OCFS2.

Si on montait directement nos bases de données et nos sites sur les drbd après les avoir formatés avec un file sytem non clusterisé cela ne fonctionnerait pas. Car le but est que le forum puisque ecrire dans la base des deux cotés que les deux serveurs soient actifs en même temps et aient un accès concurrents au stockage. Pour cela il nous faut un systeme de fichier qui gere les accès concurrents sur un même espace de stockage (es 2 plus connus sont OCFS2 et GFS) installons OCFS2

root@node1#apt-get install ocfs2-tools

On créer le répertoire /etc/ocfs2

root@node1#mkdir /etc/ocfs2

On édite un fichier cluster.conf (identique sur les deux noeuds)

node: ip_port = 7777 ip_address = 88.191.84.35 number = 0 name = node1 cluster = ocfs2 node: ip_port = 7777 ip_address = 88.191.84.36 number = 1 name = node2 cluster = ocfs2 cluster: node_count = 2 name = ocfs2

Changer la valeur “O2CB_ENABLED=false” en “O2CB_ENABLED=true” dans /etc/default/o2cb

On demmarre alors le cluster OCFS2

on peut alors formater nos devices drbd en ocfs2

root@node1#mkfs -t ocfs2 /dev/drbd0
root@node1#mkfs -t ocfs2 /dev/drbd1

Le faire sur un seul noeud suffit puisque drbd à dejà repliqué ce file system de l'autre coté.

Voilà le cluster est prêt à recevoir les données.

Pour ma part j'avais installé lamp avant et j'ai transferé les données sur les nouveaux montages.

root@node1#mount /dev/drbd0 /var/www root@node1#mount /dev/drbd1 /var/lib/mysql

Par contre il est important de désactiver tous les system de cache dans mysql. Car si ocfs2 est capable de gerer la cohérence sur son systeme disk, evidemment il ne peut pas gerer la cohérence entre les caches des deux serveurs Mysql qui tournent en même temps. En tatonnant un peu, j'ai réussi à faire demmarer les deux serveur mysql avec ce fichier de conf.

# # The MySQL database server configuration file. # # You can copy this to one of: # - "/etc/mysql/my.cnf" to set global options, # - "~/.my.cnf" to set user-specific options. # # One can use all long options that the program supports. # Run program with --help to get a list of available options and with # --print-defaults to see which it would actually understand and use. # # For explanations see # http://dev.mysql.com/doc/mysql/en/server-system-variables.html # This will be passed to all mysql clients # It has been reported that passwords should be enclosed with ticks/quotes # escpecially if they contain "#" chars... # Remember to edit /etc/mysql/debian.cnf when changing the socket location. [client] port = 3306 socket = /var/run/mysqld/mysqld.sock # Here is entries for some specific programs # The following values assume you have at least 32M ram # This was formally known as [safe_mysqld]. Both versions are currently parsed. [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] # # * Basic Settings # #innodb_data_home_dir = # ## Le fichier de donné doivent contenir vos donné et index. #innodb_data_file_path = /ibdata/ibdata1:2000M; ## ## Utilisez un buffer de taille 50 à 0 % de votre méire serveur ## mais assurez vous sous Linux que l'utilisation totale est inféeure à Go #set-variable = innodb_buffer_pool_size=1G #set-variable = innodb_additional_mem_pool_size=20M #innodb_log_group_home_dir = /dr3/iblogs ## ## innodb_log_arch_dir doit êe le mê que innodb_log_group_home_dir ## (starting from 4.0.6, you can omit it) #innodb_log_arch_dir = /dr3/iblogs #set-variable = innodb_log_files_in_group=2 ## ## Utilisez un fichier de log de taille 15 % du buffer méire #set-variable = innodb_log_file_size=250M #set-variable = innodb_log_buffer_size=8M ## #innodb_flush_log_at_trx_commit=1 #set-variable = innodb_lock_wait_timeout=50 ## ## Démmentez les prochaines lignes, si vous voulez les utiliser ##innodb_flush_method=fdatasync ##set-variable = innodb_thread_concurrency=5 # # # * IMPORTANT # If you make changes to these settings and your system uses apparmor, you may # also need to also adjust /etc/apparmor.d/usr.sbin.mysqld. # user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp language = /usr/share/mysql/english skip-external-locking = 0 # # Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. bind-address = 127.0.0.1 # # * Fine Tuning # key_buffer = 0 key_buffer_size = 0 max_allowed_packet = 16M thread_stack = 128K thread_cache_size = 0 #max_connections = 100 #table_cache = 64 #thread_concurrency = 10 # # * Query Cache Configuration # query_cache_type = 0 query_cache_limit = 0 query_cache_size = 0 # # * Logging and Replication # # Both location gets rotated by the cronjob. # Be aware that this log type is a performance killer. log = /var/log/mysql/mysql.log # # Error logging goes to syslog. This is a Debian improvement :) # # Here you can see queries with especially long duration #log_slow_queries = /var/log/mysql/mysql-slow.log #long_query_time = 2 #log-queries-not-using-indexes # # The following can be used as easy to replay backup logs or for replication. # note: if you are setting up a replication slave, see README.Debian about # other settings you may need to change. #server-id = 1 #log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 100M #binlog_do_db = include_database_name #binlog_ignore_db = include_database_name # # * BerkeleyDB # # Using BerkeleyDB is now discouraged as its support will cease in 5.1.12. skip-bdb # # * InnoDB # # InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/. # Read the manual for more InnoDB related options. There are many! # You might want to disable InnoDB to shrink the mysqld process by circa 100MB. #skip-innodb # # * Security Features # # Read the manual, too, if you want chroot! # chroot = /var/lib/mysql/ # # For generating SSL certificates I recommend the OpenSSL GUI "tinyca". # # ssl-ca=/etc/mysql/cacert.pem # ssl-cert=/etc/mysql/server-cert.pem # ssl-key=/etc/mysql/server-key.pem [mysqldump] quick quote-names max_allowed_packet = 16M [mysql] #no-auto-rehash # faster start of mysql but no tab completition [isamchk] key_buffer = 0 # # * NDB Cluster # # See /usr/share/doc/mysql-server-*/README.Debian for more information. # # The following configuration is read by the NDB Data Nodes (ndbd processes) # not from the NDB Management Nodes (ndb_mgmd processes). # # [MYSQL_CLUSTER] # ndb-connectstring=127.0.0.1 # # * IMPORTANT: Additional settings that can override those from this file! # The files must end with '.cnf', otherwise they'll be ignored. # !includedir /etc/mysql/conf.d/

J'ai alors installé le forum PunBB sur un noeud, qui s'est bien sur instantanément répliqué sur l'autre.

Quand j'ai parlé d'équilibrage de charge dans le titre, je l'obtient en utilisant simplement un round robin au niveau DNS. C'est à dire 2 enregistrement A avec le meme nom qui pointent sur les 2 ip de mon cluster.

forum.info16.fr. IN A 88.191.84.35 forum.info16.fr. IN A 88.191.84.36

Ainsi aléatoirement un utilisateur cherchant à se connecter au forum forum.info16.fr sera diriger vers 88.191.84.35 ou 88.191.84.36 Attention on ne gere pas du tout le failover. Si un serveur plante l'utilisateur aura une chance sur 2 d'etre dirigé vers le site innaccessible.

Et même si on essait de gerer le DNS afin qu'il detecte si un serveur est innaccessible et modifie ces enregistrements en conséquence, on ne pourra jamais gérer le cache DNS des clients qui se connectent... Ils auront une ip innaccessible jusqu'au TTL. d'ou l'importance de mettre des TTL bas pour les round robin.

27 juillet 2011 1 commentaire

#Gnu/Linux

Installation de OpenSuse sur une dédibox

Ce billet me sert de petit aide mémoire pour installer une OpenSure sur un serveur dédié type dédibox... Vous vous demandez peut être ou est la difficulté? Et bien le problème est que Suse ne fait pas partie des distributions installable dans la console de gestion de dédibox. Donc problème, comment installer une distribution quand elle ne fait pas partie du package de l'herbergeur?

Heureusement Novell à penser à tout la Netinstall

Ce dont vous avez besoin pour réaliser une installation par le réseau est de démarrer le noyau d'installation ainsi que le programme d'installation initrd sur la machine distante. Vous avez aussi besoin de connaître l'adresse IP que l'ordinateur aura. Supposons que c'est une adresse IP fixe. Si vous utilisez DHCP, vous pouvez omettre la configuration du réseau. Tout d'abord, copier l'image du noyau et le programme d'installation dans votre répertoire /boot :

Tout d'abord installer une distribution proposée par dédibox par exemple une Debian. Booter sur le systeme installé.

On peut commencer:

Exemple pour la dernière version de développement:

cd /tmp wget http://mirrors.kernel.org/opensuse/distribution/SL-OSS-factory/inst-source/boot/i386/loader/linux wget http://mirrors.kernel.org/opensuse/distribution/SL-OSS-factory/inst-source/boot/i386/loader/initrd cp linux /boot/vmlinuz.install cp initrd /boot/initrd.install

Vous avez maintenant le kernel et l'initrd qui permette de booter sur un systeme minimum et lancer l'installation par le réseau.

Afin de lancer l'install par le réseau il faut modifier le grub afin de lancer SSH et d'indiquer le chemin réseau de l'install

vim /boot/grub/menu.lst

On rajoute alors les lignes du type:

title Boot -- SUSE LINUX DEVEL INSTALL root (hd0,0) kernel /boot/vmlinuz.install usessh=1 sshpassword="pass" install=http://204.152.191.7/opensuse/distribution/SL-OSS-factory/inst-source hostip=192.168.1.1 netmask=255.255.255.0 gateway=192.168.1.254 nameserver=192.168.1.254 initrd /boot/initrd.install

bien sur ceci si votre grub est installé sur la première partition du premier disque (hd0,0) = (sda1) et si votre ip est 192.168.1.1/24 votre passerelle 192.168.1.254 et votre dns 192.168.1.254

Mettre cette entrée en premier afin que le boot se fasse avec ces options. Si tout se passe bien vous devriez bientot pinger a nouveau votre serveur: Il est en train de booter sur le kernel minimal d'installation.

Après quelques minutes vous pourrez vous connecter en SSH sur le serveur

ssh -X 192.168.1.1

-X pour exporter aussi la session graphique. une fois connecté vous pouvez lancer yast.

L'installation peut commencer comme d'habitude

27 juillet 2011 Aucun commentaire

#Gnu/Linux

Expérimentation de NBD (Network Block device), ou comment exporter un périphérique type bloc par le réseau

Il y a quelque temps, j'ai fait un petit article sur le protocole isci et l'export de périphérique bloc via ce protocole... J'ai toutefois découvert il y a peu de temps une facon encore plus simple d'exporter un Block device par le réseau : NBD ou network block device

Je vous laisse installer le nbd-server et le nbd-client sur votre distribution préférée... Pour ma part j'ai fait les tests sur une OpenSuse 11 pour le serveur et une Ubuntu Hardy pour le client... Que se soit avec yast ou a coup d'apt-get vous installerez facilement les paquets nbd.

Bref...

Si vous avez lu mon blog en entier, vous savez comment mettre en place LVM2, dont je me suis servi pour faire mes test, c'est tellement pratique de disposer d'un périphérique block avec une simple commande...

Sur le Serveur: Commencons par créer un block device avec LVM2

xenserver:~ # lvcreate -L1G -ndisk vg0 Logical volume "disk" created

Exportons le directement via nbd

xenserver:~ # nbd-server 3000 /dev/vg0/disk

La commande est simple, on demande à nbd-server d'exporter le block-device /dev/vg0/disk via le port 3000

Nous pouvons vérifier que nbd-server écoute bien sur le port 3000 et n'attend plus que la connexion de son client

xenserver:~ # netstat -anp | grep 3000 tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 16358/nbd-server

Passons maintenant au client: Sur Ubuntu j'ai dut installer lvm2, (noter que lvm2 n'est pas du tout indispensable, c'est juste que je le trouve très souple à utiliser pour mes tests, mais rien ne vous empêche de créer des periphérique via losetup et les periphérique /dev/loop) Il a fallut bien sur installer nbd-client et dans la foulée j'ai installé mdadm pour gerer le raid...

Bref, commencons par se connecter au serveur et importons notre block device...

root@bartounet:/media# nbd-client 192.168.1.115 3000 /dev/nbd2 Negotiation: ..size = 1048576KB bs=1024, sz=1048576

Ici on se connecte sur le port 3000 du serveur et on importe le nbd en local sur /deb/nbd2

Voila le tour est joué notre device /dev/nbd2 est vu comme un simple device local de notre systeme, mais est en réalité exporté par le réseau...

Comme j'aime faire quelques petits tests, nous allons pas nous arreter là, je vais tester la vitesse de ce block-device.

Pour cela rien de plus simple, un petit dd va nous permettre de voir la vitesse...

root@bartounet:/media# dd if=/dev/nbd2 of=/dev/zero bs=1M 1024+0 records in 1024+0 records out 1073741824 bytes (1,1 GB) copied, 13,3121 s, 80,7 MB/s

C'est pas mal, je sature presque mon lien réseau, puisque mes deux postes sont réliés via un réseau gigabits donc en théorie pouvant atteindre les 120Mo/s Ceci est un test en lecture sur /dev/nbd2

Pour nous en convaincre un petit iperf entre les deux machines:

root@bartounet:/media# iperf -cxenserver ------------------------------------------------------------ Client connecting to xenserver, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.100 port 35157 connected with 192.168.1.115 port 5001 [ 3] 0.0-10.0 sec 1.09 GBytes 936 Mbits/sec

En effet on a bien un lien gigabit entre les deux.. ;-)

Pour être transparent je souhaite donner les performances disques disponibles pour les deux machines:

Les configs:

Xenserver: AMD Athlon 64 X2 5000+ Black edition à 2600Mhz 2Go DDR2 2 disques sata WDC WD1600YS (raid edition 160Go) en RAID0 logiciel

xenserver:~ # dd if=/dev/md0 of=/dev/zero bs=2M 1260388352 bytes (1.3 GB) copied, 10.4169 s, 121 MB/s

Bartounet: Intel Quad Core Q6600 G0 à 2400Mhz 2Go DDR2 2 disques sata Hitachi T7K500 250Go Raid0 matériel (puce raid Asus P5WDh deluxe)

root@bartounet:/media# dd if=/dev/sda of=/dev/zero bs=2M 616562688 bytes (617 MB) copied, 4,90903 s, 126 MB/s

Pour finir je me suis dit mais pourquoi pas faire un raid entre un block-device local sur BARTOUNET et un block-device nbd.

Pour cela je crée un block-device local sur bartounet toujours à l'aide de lvm2

root@bartounet:/media# lvcreate -L1G -nraid vgxen Logical volume "raid" created

Maintenant nous pouvons creer le périphérique raid avec mdadm

root@bartounet:/media# modprobe raid0 root@bartounet:/media# mdadm --create /dev/md1 --level=0 --raid-device=2 /dev/vgxen/raid /dev/nbd2 mdadm: array /dev/md1 started.

Notre raid est bien monté

root@bartounet:/media# mdadm --detail /dev/md1 /dev/md1: Version : 00.90.03 Creation Time : Sun Jun 22 19:36:35 2008 Raid Level : raid0 Array Size : 2097024 (2048.22 MiB 2147.35 MB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 1 Persistence : Superblock is persistent Update Time : Sun Jun 22 19:36:35 2008 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Chunk Size : 64K UUID : 6b2edcd4:b994fefd:20bc8809:0761db64 (local to host bartounet) Events : 0.1 Number Major Minor RaidDevice State 0 254 1 0 active sync /dev/vgxen/raid 1 43 2 1 active sync /dev/nbd2

testons tout de suite la vitesse en lecture sur ce raid0 qui je vous rappelle est un raid0 entre un periphérique local /dev/vgxen/raid et un network block device /dev/nbd2 (exporté de Xenserver)

root@bartounet:/media# dd if=/dev/md1 of=/dev/zero 4194048+0 records in 4194048+0 records out 2147352576 bytes (2,1 GB) copied, 12,8236 s, 167 MB/s

Et voila on obtient un périphérique exploitant la vitesse des deux block device ( un local et un réseau) Marrant non ?

Bon la je me suis attaché aux performances mais rien ne vous empeche de faire du mode sécurisé en raid1 ou plus...

27 juillet 2011 Aucun commentaire

#Gnu/Linux

Mise en place du protocole iscsi (Target Linux/OpenSuse-10.3, Initiator Windows XP Sp2)

Sous le vocable iSCSI (à prononcer i-skeuzi, i-skozi, aïe-skeuzi ou aïe-skozi selon que vous adoptez une prononciation française ou anglophone), se cache un protocole réseau qui encapsule le protocole SCSI dans des paquets TCP. TCP/IP est alors utilisé comme protocole de transport ce qui permet à une machine d’accéder à des périphériques distants connectés à l’infrastructure réseau existante. Le protocole iSCSI (voir RFCA) utilise l’architecture client/serveur, mais possède sa propre terminologie : le client est appelé « initiator » le serveur est appelé « target » Je vais essayer dans ce billet de monter une petite Archi entre une Target Linux et un initiator Windows Xp L’initiator peut être une carte Ethernet spécialisée, munie d’un composant supplémentaire qui va gérer le protocole iSCSI. Cette carte sera appelée un « iSCSI-HBA ». Mais, on peut aussi déployer une solution logicielle pure qui nécessite seulement un driver spécifique dont le rôle sera de traduire les ordres SCSI en paquets réseau. C’est cette solution que nous allons mettre en œuvre dans cet article. La target (cible) est normalement un périphérique de stockage doté d’une interface iSCSI. Qu’est-ce-qu’une interface iSCSI ? Eh bien en fait, les constructeurs proposent, outre la connectivité Fibre Channel, un ou plusieurs ports Ethernet avec support au niveau de l’OS et éventuellement des cartes réseau, du protocole iSCSI. Mais pour ceux qui ne disposent pas d’un tel matériel, nous verrons comme émuler une target avec Linux ! Initiator et target sont considérés comme les nœuds d’un réseau iSCSI. Le driver iSCSI transporte les commandes SCSI sur le réseau plutôt que d’utiliser un bus SCSI directement connecté ou bien une connexion en FC. ISCSI Mon protocole de test: Serveur 1: La target iscsi (opensuse 10.3) AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ Black Edition (2600Mhz) 2Go ddr2 Crucial Balistic (4-4-4-12) Carte Mère Asus M3A 1 HDD SAMSUNG HD160JJ pour le systeme 2 HDD Western digital WDC WD1600YS (raid edition) en Raid 0 ----> pour stockage LVM Lan intégré à la carte Mère chipset Atlansic Gigabit Serveur 2: L'initiator Intel Q6600 Quad Core (2400Mhz) 2Go ddr2 Crucial Balistic Carte mère P5WDH Deluxe 2 HDD hitachi 7200Tpm 250Go T7K500 en Raid0 matériel Lan Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller Bref, c'etait juste pour être précis sur le protocole de test.... Lorsque l’initiator souhaite établir une session TCP avec la target, il a besoin de connaître le port TCP de la target. L’association (adresse IP, port TCP) est appelé un « portal ». Il y a donc un portal sur l’initiator et la target. Le port par défaut sur la target est le 3260. Notons qu’un initiator peut établir plusieurs connexions TCP avec la même cible. L’ensemble de ces connexions définit une « session iSCSI ». Pour l'installation j'ai été cherché les sources de l'application iscsi-target qui au moment ou j'écris ces lignes est en version 0.4.16 [http://sourceforge.net/project/showfiles.php?group_id=108475&package_id=117141&release_id=585138|http://sourceforge.net/project/showfiles.php?group_id=108475&package_id=117141&release_id=585138|fr] Après avoir téléchargé iscsi target on l'extrait
xenserver:~ # tar xvfz iscsitarget-0.4.16 xenserver:~ # cd iscsitarget-0.4.16/
Il va maintenant falloir compiler et installer le logiciel... Il y a tout de même des prérequis: La target doit avoir un kernel linux au minimum 2.6.16 On doit disposer d'un compilateur gcc, des entetes de notre noyeau et des fichiers d’en-têtes de la bibliothèque OpenSSL. Après ces petites verification on compile et on installe:
xenserver:~/iscsitarget-0.4.16 # make xenserver:~/iscsitarget-0.4.16 # make install
On a donc maintenant: # iscsi_trgt.ko : un module noyau qui émule une cible iSCSI et implémente le protocole ; # un démon ietd (IET = iSCSI Enterprise Target) ; # une commande de contrôle ietadm ; # quelques fichiers de configuration On peut tout de suite crée une target iscsi... Pour cela rien de plus simple: Il faut savoir que les adresses iscsi peut vent avoir 2 formes: Les adresses iSCSI peuvent avoir deux formats (voir [RFCB]) : * Le format iqn (iSCSI Qualified Name) : c’est une chaîne préfixée par « iqn. » et suivie d’une date (au format AAAA-MM), du nom de l’autorité qui a attribué le nom (c’est le nom de domaine à l’envers), puis une chaîne unique qui identifie le nœud. Par exemple : iqn.2007-07.org.zereso:serveur1:123456789ABCDEF.12345. * Le format eui (Enterprise Unique Identifier) : c’est une chaîne préfixée par « eui. » et suivie de 16 chiffres hexadécimaux. Par exemple : eui.00803A4B887A8D05. On va donc aller éditer le fichier ietd.conf
xenserver:~/iscsitarget-0.4.16 # vi /etc/ietd.conf
# iqn.yyyy-mm.[:identifier] # # "yyyy-mm" is the date at which the domain is valid and the identifier # is freely selectable. For further details please check the iSCSI spec. Target iqn.2008-04.lan.appart:storage.disk # Users, who can access this target. The same rules as for discovery # users apply here. # Leave them alone if you don't want to use authentication. #IncomingUser joe secret #OutgoingUser jim 12charpasswd # Logical Unit definition # You must define one logical unit at least. # Block devices, regular files, LVM, and RAID can be offered # to the initiators as a block device. Lun 0 Path=/dev/vg0/luniscsi,Type=blockio # Alias name for this target # Alias Test # various iSCSI parameters # (not all are used right now, see also iSCSI spec for details) #MaxConnections 1 #InitialR2T Yes #ImmediateData No #MaxRecvDataSegmentLength 8192 #MaxXmitDataSegmentLength 8192 #MaxBurstLength 262144 #FirstBurstLength 65536 #DefaultTime2Wait 2 #DefaultTime2Retain 20 #MaxOutstandingR2T 8 #DataPDUInOrder Yes #DataSequenceInOrder Yes #ErrorRecoveryLevel 0 #HeaderDigest CRC32C,None #DataDigest CRC32C,None # various target parameters #Wthreads 8
Le fichier parle de lui même j'ai déclaré une cible qui est Target iqn.2008-04.lan.appart:storage.disk et un périhpérique cible en mode bloc appelé une LUN qui est /dev/vg0/luniscsi,Type=blockio Avant de démarrer le demon iscsi-target, je vais quand même créer mon disque puisqu'il n'existe pas encore ;-) Pour cela j'utilise l'excellent systèmes LVM2 Le système de LVM insère des sous-couches entre la partition de disque et votre système de fichier (là où sont vos données). Ces sous-couches vont vous permettre de modifier dynamiquement la taille des systèmes de fichier, sans mettre en péril vos données. Ainsi vous pourrez ajouter, enlever de l'espace disque d'un filesystem à la volée, rajouter un système de fichier... sans modification de la table des partitions. crééons notre disque:
xenserver:~/iscsitarget-0.4.16 # lvcreate -L5G -nluniscsi vg0 Logical volume "luniscsi" created
(il faut bien sur avoir préalabement configurer son système disque pour fonctionner avec le systeme lvm2 et creee les volume groups) J'ai donc un volume logique de 5G qui n'est autre que ma LUN qui va pouvoir être exportée sur le réseau vers l'initiator. démarrons alors le demon target iscsi
xenserver:~/iscsitarget-0.4.16 # /etc/init.d/iscsi-target start
à partir de là on va pouvoir aller s'occuper de l'initiator... Mais comme on est sérieux on va aller quand même vérifier que nos cilbe sont biens exportées pour cela on va directement regarder dans:
xenserver:~/iscsitarget-0.4.16 # cat /proc/net/iet/volume tid:1 name:iqn.2008-04.lan.appart:storage.disk lun:0 state:0 iotype:blockio iomode:wt path:/dev/vg0/luniscsi
Ouf on retrouve bien notre target associé à notre lun... Maintenant passons sous Windows... Je mettrais à jour plus tard ce post, pour monter aussi l'initiator sous Gnu/Linux, mais ce n'est pour l'instant pas ma priorité, puisque pour ma part j'utilise que des clients Windows, qui se connectent sur du serveur Gnu/Linux... Sous Windows Xp Sp2 l'initiator isci n'est pas installé par défaut, j'ai installé pour ma part Initiator-2.06 [http://www.microsoft.com/Downloads/details.aspx?familyid=12CB3C1A-15D6-4585-B385-BEFD1319F825&displaylang=en|http://www.microsoft.com/Downloads/details.aspx?familyid=12CB3C1A-15D6-4585-B385-BEFD1319F825&displaylang=en|fr] Uns fois installé on lance l'initiateur iscsi. On ajoute l'ip de notre target iscsi1 iscsi2 On va voir dans le gestionnaire des disques Et miracle notre lun est apparu comme un disque à part entière iscsi3 Après une creation de partition et un formatage en ntfs iscsi4 Notre LUN iscsi est bien monté sur notre initiator... On peut maintenant l'utiliser comme les autres disques... Pour finir mon test, j'ai voulu quand même vérifier le débit de cette lun. Comme nous l'avons vu plus haut, la lun est basé sur un logical volume crée sur mon raid0 (raid0 logiciel Linux) de deux disques Western Digital WD1600YS Pour savoir quelles sont les performances de départ, voici un petit dd sur le raid en question
xenserver:~ # dd if=/dev/md0 of=/dev/zero bs=16M 125+0 records in 124+0 records out 2080374784 bytes (2.1 GB) copied, 19.9423 s, 104 MB/s
C'est un raid0 sur deux disques qui vont chacun à 63Mo/s en vitesse séquentielle... Cela dépend des tests, en raid0 la vitesse varie entre 100 et 126Mo/s Faisons le test de vitesse sur la lun sous Windows... speed On peut voir qu'on monte à environ 60Mo/s sur la Lun, ce qui n'est pas mal mais qui pourrait etre mieux... En effet le lien réseau entre les deux n'est pas limité... La preuve avec iperf entre l'initiator et la target
C:\>iperf.exe -w512k -c192.168.1.115 ------------------------------------------------------------ Client connecting to 192.168.1.115, TCP port 5001 TCP window size: 512 KByte ------------------------------------------------------------ [1916] local 192.168.1.100 port 2500 connected with 192.168.1.115 port 5001 [ ID] Interval Transfer Bandwidth [1916] 0.0-10.3 sec 1.10 GBytes 922 Mbits/sec
On pourrait tunner notre pile tcp/ip pour atteindre de bien meilleurs résultats, notemment en activant les jumbo Frames (Paquets géants) mais la carte nic intégré à l'asus M3A ne semble pas le supporter... Elle ne supporte pas non plus le TCP Checksum offloader (toe)... les réglages sont donc assez restreints....
27 juillet 2011 Aucun commentaire