Objectif

En vedette

Bonjour,

Voici le premier post de ce blog dont l’objectif principal va être de vous faire partager mon point de vue sur différentes technologies que j’apprécie.

Les sujets seront principalement le stockage, la virtualisation et linux.

Je vous invite à commenter, critiquer et me contacter afin d’améliorer les différents posts.

En tout cas, merci à tous ceux qui me suivront et qui m’aideront et a bientôt pour le vrai départ.

nov 04

Linux dns

Voici mon premier article pour linux, et on va commencer par la configuration d’un dns, bind.

L’installation se fait sur un centos 7 en version minimal.

Pour commencer nous allons installer les packages necessaire:

yum install bind bind-chroot bind-utils

Nous installons la version chroot pour plus de securite. Attention depuis rhel6 la configuration de votre bind ne se fait plus directement dans le chroot, au contraire il faut faire cotre configuration comme si vous n’etiez pas chrooter et c’est lors du demerage du service que l’OS va alors monter votre configuration dans le chroot.

Afin d’avoir une meilleur lisibilite je ne declare jamais mes zones directement dans le named.conf. Je creer des fichiers dedies a cela que j’inclue dans le named.conf. Cela multiplie le nombre de fichier mais je trouve ca lus simple a manager par la suite.

On commence par configurer notre server master (normalement se server ne derait repondre a aucune requete dns, il doit juste servir a mettre a jour les configurations et transferer les zones au slave, mais pour ne pas saturer mon lab avec 3 server DNS, ici notre master pourra repondre au requete).

nano /etc/named.conf ->

#On cree une acl afin de limiter les acces a notre serveur dns
acl internals{
    192.168.1.0/24;
    192.168.100.0/24;
    192.168.101.0/24;
    192.168.102.0/24;
    127.0.0.1/32;
};

options{
    #on ecoute sur le port 53 sur les interfaces de loopback et sur l’interface eth0
    listen-on port 53 { 127.0.0.1;192.168.1.101; };

#On definit l’endroit ou seront stocker les differents fichiers de conf et de stats
directory         « /var/named »;
    dump-file        « /var/named/data/cache_dump.db »;
    statistics-file        « /var/named/data/named_stats.txt »;
    memstatistics-file    « /var/named/data/named_meme_stats.txt »;

#On accepte des requetes seulement si ca provient de l’ACL internals
   allow-query { internals; };

#On accepte de transferer les informations de zone aux serveurs possedant la cle TRANSFER
 allow-transfer { key TRANSFER; };

 #Lors d’une mise a jour d’une zone sur le server master on va notifier les servers slaves
allow-notify { 192.168.1.102; };
    also-notify { 192.168.1.102; };

#On permet a notre serveur de repondre en mode recursif
allow-recursion { internals; };
    recursion yes;

 #Activer la securite dnssec qui fait que chauqe transaction est cryptee
   dnssec-enable yes;
    dnssec-validation yes;
    dnssec-lookaside auto;

    bindkeys-file « /etc/named.iscdlv.key »;

        managed-keys-directory « /var/named/dynamic »;

        pid-file « /run/named/named.pid »;
        session-keyfile « /run/named/session.key »;
};

# declaration du mode de log, le severity dynamic suffit la plupart du temps mais si necessaire vous pouvez le forcer en mode debug
logging {
    channel default_debug {
        file « data/named.run »;
        severity dynamic;
    };
};

zone « . » IN {
    type hint;
        file « named.ca »;
};

# declaration des fichiers qui vont definir nos differentes zones
include « /etc/named.rfc1912.zones »;
include « /etc/named.root.key »;
include    « /etc/named/named.global.zones »;
include    « /etc/named/named.reverse.global.zones »;
include    « /etc/named/named.linux.zones »;
include « /etc/named/named.reverse.linux.zones »;
include    « /etc/named/named.isilon.zones »;
include    « /etc/named/named.reverse.isilon.zones »;
include    « /etc/named/named.veeam.zones »;
include    « /etc/named/named.reverse.veeam.zones »;

Notre named.conf est maintenant terminer. Nous allons nous occuper des fichiers de zones.

nano /etc/named/named.global.zones ->

#nom de    la zone
zone « noonworld.local » {
        #Nous sommme sur le server master, la zone sera    donc de    type master
        type master;
        #on permet le transfert    de cette zone a    tous les servers possedant la cle TRANSFER
        allow-transfer {Key TRANSFER; };
        #On notifiera les servers slaves lors de la mise a jout    de cette zone
        notify yes;
        #Le fichier de cette zone est:
        file « /var/named/data/db.noonworld.local.conf »;
};

P.S: dans le cadre d’une zone reverse le nom de la zone se forme comme ceci:

zone « 1.168.192.in-addr.arpa » {

Nos differentes zones sont decalres, ils faut maintenant les completes.

nano /var/named/data/db.noonworld.local.conf ->

#TTL value
$TTL 86400
#owner-name, @    #class,    IN=internet    #authoritative name-server    #email du responsable
@          IN              SOA     ns1.noonworld.local.            noon.noonworld.fr. (
                2014110401    ;serial    doit etre augmenter a chaque modification   
                        6H    ;refresh temps pour que le slave demande une update au master
                        1H    ;retry temps avant nouvelle tentative du slave si il y a un probleme
                        1W      ;expire temps avant que le slave ne soit plus autoritaire sans contact avec le master
                        1D )    ;TTL temps de caching

                #server dns pour cette zone
                NS ns1.noonworld.local.
                NS ns2.noonworld.local.

#nom            #type d’enregistrement    #@IP
hcnas          A                                        192.168.1.175
esxi1           A                                         192.168.1.152
esxi2           A                                         192.168.1.154
ns1             A                                         192.168.1.101
ns2             A                                         192.168.1.102

Enfin la dernier etape, la generation de la cle TRANSFER.

dnssec-keygen -a HMAC-MD5 -b 128 -n HOST rndc-key

Cette commande genere 2 fichiers. Il faut faire un cat sur le fichier genere .key afin de recuperer la cle et ensuite cree le fichier tsig.key avec cette cle.

nano /etc/tsig.key ->

# definition de    la cle TRANSFER
key « TRANSFER » {
        #algorithm utilise pour    generer    la cle
        algorithm hmac-md5;
        # valeur de la cle
        secret « /8rbYMJGVGY5mCm3Y2omAg== »;
};

#definition des    servers    slaves
server 192.168.1.102 {
keys {TRANSFER; };
};

Le server master est maintenant pret a l’utilisation. Avant de starter bind il vous faut ajouter une regle dans le firewall pour accepter le traffic dns.

 firewall-cmd –add-service dns
 firewall-cmd –permanent –add-service dns
 firewall-cmd –reload

Et starter le service bind:

systemctl start named
systemctl enable named

Vous pouvez voir l’etat de votre dns en regardant le fichier de log /var/log/messages.

Nous allons maintenant configurer notre dns slave, installons les paquets necessaire:

yum install bind bind-chroot bind-utils

Et modifions notre fichier de conf, qui en realite tres proche de celui du master.

nano /etc/named.conf ->

#On cree une acl afin de limiter les acces a notre serveur dns
acl internals{
    192.168.1.0/24;
    192.168.100.0/24;
    192.168.101.0/24;
    192.168.102.0/24;
    127.0.0.1/32;
};

options{
    #on ecoute sur le port 53 sur les interfaces de loopback et sur l’interface eth0
    listen-on port 53 { 127.0.0.1;192.168.1.102; };

#On definit l’endroit ou seront stocker les differents fichiers de conf et de stats
directory         « /var/named »;
    dump-file        « /var/named/data/cache_dump.db »;
    statistics-file        « /var/named/data/named_stats.txt »;
    memstatistics-file    « /var/named/data/named_meme_stats.txt »;

#On accepte des requetes seulement si ca provient de l’ACL internals
   allow-query { internals; };

#On accepte de transferer les informations de zone aux serveurs possedant la cle TRANSFER
 allow-transfer { key TRANSFER; };

 #Lors d’une mise a jour d’une zone sur le server master on va notifier les servers slaves
allow-notify { 192.168.1.101; };

#On permet a notre serveur de repondre en mode recursif
allow-recursion { internals; };
    recursion yes;

 #Activer la securite dnssec qui fait que chauqe transaction est cryptee
   dnssec-enable yes;
    dnssec-validation yes;
    dnssec-lookaside auto;

    bindkeys-file « /etc/named.iscdlv.key »;

        managed-keys-directory « /var/named/dynamic »;

        pid-file « /run/named/named.pid »;
        session-keyfile « /run/named/session.key »;
};

# declaration du mode de log, le severity dynamic suffit la plupart du temps mais si necessaire vous pouvez le forcer en mode debug
logging {
    channel default_debug {
        file « data/named.run »;
        severity dynamic;
    };
};

zone « . » IN {
    type hint;
        file « named.ca »;
};

# declaration des fichiers qui vont definir nos differentes zones
include « /etc/named.rfc1912.zones »;
include « /etc/named.root.key »;
include    « /etc/named/named.global.zones »;
include    « /etc/named/named.reverse.global.zones »;
include    « /etc/named/named.linux.zones »;
include « /etc/named/named.reverse.linux.zones »;
include    « /etc/named/named.isilon.zones »;
include    « /etc/named/named.reverse.isilon.zones »;
include    « /etc/named/named.veeam.zones »;
include    « /etc/named/named.reverse.veeam.zones »;

La aussi nous devons declare nos fichiers de zones:

nano /etc/named/named.global.zones ->

#nom de    la zone
zone « noonworld.local » {
        #Nous sommme sur le server slave, la zone sera donc de type slave
        type slave;
        #on definit le server master
        masters {192.168.1.101; };
        #Le fichier de cette zone est:
        file « /var/named/data/db.noonworld.local.conf »;
};

Et enfin la cle TSIG:

nano /etc/tsig.key ->

# definition de    la cle TRANSFER
key « TRANSFER » {
        #algorithm utilise pour    generer    la cle
        algorithm hmac-md5;
        # valeur de la cle
        secret « /8rbYMJGVGY5mCm3Y2omAg== »;
};

#definition des    servers    masters
server 192.168.1.101 {
keys {TRANSFER; };
};

Lorsque nous allons start le service il va alors se connecter au server master afin de telecharger les differents fichier de zone.

 firewall-cmd –add-service dns
 firewall-cmd –permanent –add-service dns
 firewall-cmd –reload

Et starter le service bind:

systemctl start named
systemctl enable named

 

Je rajouterai par la suite la partie necessaire pour que lorsque je deploie un server linux il puisse s’enregister automatiquement dans notre dns.

N’ayant pas de DMZ je n’ai pas fait de view sur ce server, mais je rajouterai peut etre un article un jour expliquant cette partie.

Si vous avez des conseils ou des astuces surtout n’hesitez pas.

 

sept 01

Nouveau NAS

Hello,

alors comme je le disais j’ai attendu de monter un nouveau nas avant de tester nexenta 4. En effet mon ancien nas ne fournissait pas suffisamment d’IO pour mon environnement.  Pour ce nouveau nas je suis parti sur du matériel un peu plus professionnel:

– carte mère: supermicro a1sai-2750f (attention l’intel 2750 chauffe pas mal, ventiler bien votre boîtier)       – 32 gb de ram ecc (ddr3 pc 10600, la carte mère ne supporte que de la so-dimm et il n’est pas simple de trouver de la so-dimm en ecc)                                                                                                                          – 1 intel 3700 pour le SLOG                                                                                                                              – 5 intel 3500 en raidz pour les data

Les intels 3700 et 3500 sont des ssd sata mais de gamme entreprise, c’est à dire qu’ils ont plus d’overprisonning qu’un ssd classique, mais surtout ils ont des super condensateurs afin de protéger la ram en cas de panne de courant (voir mon article sur les ssd: http://noonworld.fr/ssd/). Ces 2 points font que ces ssds sont capable de maintenir un niveau d’IO conséquent et cela même une fois rempli (le 3700 maintient 25k iops et le 3500 9k iops après le write cliff).

« Malheureusement » par defaut nexenta est configuré pour protéger vos données est n’est pas capable de tirer parti des fonctions avances de nos ssd. Il a donc fallut faire quelque réglage avant de créer le pool.

Pour cela nous allons commencer par récupérer l’ID de nos ssd grâce a cette commande:                                                                                                                                                 echo « ::walk sd_state | ::grep ‘.!=0′ | ::print struct sd_lun un_sd | \
::print struct scsi_device sd_inq | ::print struct scsi_inquiry \
inq_vid inq_pid » | mdb -k

ce qui me retourne:                                                                                                                                         inq_vid = [ « ATA      » ]
inq_pid = [ « WDC WD3200BEKT-7″ ]
inq_vid = [ « ATA      » ]
inq_pid = [ « WDC WD3200BEKT-7″ ]
inq_vid = [ « ATA      » ]
inq_pid = [ « INTEL SSDSC2BB24″ ]
inq_vid = [ « ATA      » ]
inq_pid = [ « INTEL SSDSC2BA10″ ]
inq_vid = [ « ATA      » ]
inq_pid = [ « INTEL SSDSC2BB24″ ]
inq_vid = [ « ATA      » ]
inq_pid = [ « INTEL SSDSC2BB24″ ]
inq_vid = [ « ATA      » ]
inq_pid = [ « INTEL SSDSC2BB24″ ]
inq_vid = [ « ATA      » ]
inq_pid = [ « INTEL SSDSC2BB24″ ]

Nous reconnaissons donc mon intel 3700: INTEL SSDSC2BA10 et mes 3500: INTEL SSDSC2BB24. Nous allons donc modifier le fichier /kernel/drv/sd.conf en ajoutant ces lignes a la fin :                                  vi /kernel/drv/sd.conf ->                                                                                                                 sd-config-list=
« ATA    INTEL SSDSC2BB24″, »physical-block-size:4096,throttle-max:32, disksort:false, cache-nonvolatile:true »,
« ATA    INTEL SSDSC2BA10″, »physical-block-size:4096,throttle-max:32, disksort:false, cache-nonvolatile:true »;

L’option physical-block-size:4096, indique à zfs que notre ssd utilise des secteurs de 4k et pas de 512 bytes.                                                                                                                                                              Le throttle-max:32 est du au fait que les ssd sont en sata et que la taille max de la queue en sata est de 32                                                                                                                                                      disksort:false précise que ce sont des ssd et non des disques physiques, cela indique que les commandes comme ncq/tcp ne sont pas nécessaire                                                                           cache-nonvolatile:true indique que nos ssds sont protéger contre les pannes de courant et que l’on peut donc utiliser la ram de chaque ssd.

On valide la modification du fichier par cette commande:                                                                  update_drv -vf sd

Ensuite je créer mon pool:                                                                                                                            zpool create performance raidz1 c0t55CD2E404BC0C442d0 c0t55CD2E404BC07A5Cd0 c0t55CD2E404BC07D47d0 c0t55CD2E404BC046D2d0 c0t55CD2E404BC047BFd0                                                                                                                      zpool add performance log c0t55CD2E404B5C8A07d0

Je possède 2 carte réseau sur chaque esxi dédie a mon stockage. Je vais donc créer 2 datasets afin de les présenter en nfs:                                                                                                          root@perfnas:/volumes# zfs create performance/datastore1
root@perfnas:/volumes# zfs create performance/datastore2

Puis je modifie mes options datasets afin d’activer la nouvelle compression lz4 et de forcer le passage de tous les blocs par le SLOG:                                                                                                 root@perfnas:/volumes# zfs set compression=lz4 performance/datastore1
root@perfnas:/volumes# zfs set sync=always performance/datastore1
root@perfnas:/volumes# zfs set sync=always performance/datastore2
root@perfnas:/volumes# zfs set compression=lz4 performance/datastore2

Ensuite nous modifions les paramètres du serveur nfs:                                                                                   désactiver nfsv4                                                                                                                                      augmenter le nombre de requêtes concurrentes a 2048                                                                               on augmente la taille de la queue a 64                                                                                                              on augmente le nombre concourent de lock a 1024                                                                                       et la aussi on passe la taille de la queue a 64

Enfin on share nos datastores au travers de nfs:                                                                    root@perfnas:/volumes# zfs set sharenfs=rw=@192.168.1.0/24,root=@192.168.1.152:@192.168.1.154 performance/datastore1
root@perfnas:/volumes# zfs set sharenfs=rw=@192.168.1.0/24,root=@192.168.1.152:@192.168.1.154 performance/datastore2

La première astuce de ma nouvelle config venait de la configuration des ssds, la seconde se trouve au niveau du réseau. Grace a l’utilisation des vlans et de ipmp j’ai maintenant mes 2 liens qui sont utilise en actif actif.

Premier point je liste mes interfaces physiques:                                                                 root@perfnas:/volumes# dladm show-phys
LINK         MEDIA                STATE      SPEED  DUPLEX    DEVICE
igb0         Ethernet             down       0      half      igb0
igb1         Ethernet             up         1000   full      igb1
igb2         Ethernet             up         1000   full      igb2
igb3         Ethernet             up         1000   full      igb3

Puis je cree des interfaces virtuelles avec gestion de vlan:                                                  root@perfnas:/volumes# dladm create-vnic -l igb1 NFS1 -v 2
root@perfnas:/volumes# dladm create-vnic -l igb1 NFS2 -v 3
root@perfnas:/volumes# dladm create-vnic -l igb3 NFS4 -v 3
root@perfnas:/volumes# dladm create-vnic -l igb3 NFS3 -v 2

Voici mes nouvelles interfaces virtuelles:                                                                          root@perfnas:/volumes# dladm show-vnic
LINK         OVER         SPEED  MACADDRESS        MACADDRTYPE         VID
NFS2         igb1         1000   2:8:20:dd:df:c5   random              3
NFS4         igb3         1000   2:8:20:76:f0:a1   random              3
NFS3         igb3         1000   2:8:20:65:4a:2d   random              2
NFS5         igb1         1000   2:8:20:59:21:7    random              2

 

L’objectif finale est d’arriver a ceci:    Selection_003Le but est donc d’avoir nos 2 liens actifs tout en gardant une redondance en cas de perte d’1 lien (même si cela un impact sur la performance).

création des ipmp:                                                                                                                   root@perfnas:/volumes# ifconfig ipmp0 ipmp 192.168.2.176 up
root@perfnas:/volumes# ifconfig NFS3 standby group ipmp0 up
root@perfnas:/volumes# ifconfig NFS5 group ipmp0 up                                                  root@perfnas:/volumes# ifconfig ipmp1 ipmp 192.168.3.176 up
root@perfnas:/volumes# ifconfig NFS2 -standby group ipmp1 up
root@perfnas:/volumes# ifconfig NFS4 group ipmp1 up

vérification des liens actifs (le FLAGS mb veut dire master et donc actif):                               root@perfnas:/volumes# ipmpstat -i
INTERFACE   ACTIVE  GROUP       FLAGS     LINK      PROBE     STATE
NFS4        yes     ipmp1    ——-   up        disabled  ok
NFS2        yes     ipmp1    –mb—   up        disabled  ok
NFS5        yes     ipmp0    ——-   up        disabled  ok
NFS3        yes     ipmp0    –mb—   up        disabled  ok

Enfin on rend la configuration persistante après redémarrage:                                           root@perfnas:/volumes# nano /etc/hostname.NFS2
group ipmp1 standby up
root@perfnas:/volumes#nano  /etc/hostname.NFS4
192.168.3.176/24 group ipmp1 up
root@perfnas:/volumes# nano /etc/hostname.NFS3
group ipmp0 standby up
root@perfnas:/volumes# nano /etc/hostname.NFS5
192.168.2.176 group ipmp0 up

 

Pour terminer cet article le traditionnel résultat du benchmark:                                                                     Le test est réaliser grace a 2 vmware io-analyser, 1 sur chaque datastore en mode 8k, 30% write 100% random:                                                                                                                                                        Selection_004Si on additionne les 2 on a donc un total d’environ 11500 Iops avec une latence d’environ 3ms :     Selection_005
Sachant que la conf disque peut aller un peut plus loin que ca, en effet le intel 3700 n’etait utilise qu’a 20% de ces capacités tandis que les 3500 etaient a 75%. le facteur limitant dans mon cas etait le cpu.

Mais 11 500 Iops pour un nas a environ 3000 euros, c’est deja pas si mal je trouve