J'ai récemment eu à supprimer et recréer une LUN sur un Clariion. Ladite LUN était présentée à la fois à un serveur Solaris 10 et à un serveur Linux, avec un filesystem ZFS créé sur la machine Linux et prévu pour servir d'espace de transfert.

Seulement, pas de chance, au moment de faire redécouvrir la LUN sur le serveur Solaris 10, impossible de la voir.

Les commandes que j'utilise habituellement pour cela sont les suivantes :

# cfgadm -al -o show_FCP_dev # devfsadm -Cv # powermt config

Sauf que, visiblement, ça ne suffisait pas :

# zpool import no pools available to import

En creusant un peu, j'ai découvert qu'il restait des traces de la LUN supprimée, et qu'elle empêchait la prise en compte de la nouvelle sur le même numéro de device :

# powermt display dev=all Pseudo name=emcpower77a CLARiiON ID=CKMXXXXXXXX Logical device ID=600601606FXXXXXXXXXXXXXXXX [MA_LUN] state=alive; policy=CLAROpt; priority=0; queued-IOs=0 Owner: default=SP B, current=SP B ============================================================================== ---------------- Host --------------- - Stor - -- I/O Path - -- Stats --- ### HW Path I/O Paths Interf. Mode State Q-IOs Errors ============================================================================== 3077 pci@8/SUNW,qlc@1 c3t500601623B207225d0s0 SP A2 active dead 0 1 3077 pci@8/SUNW,qlc@1 c3t500601683B207225d0s0 SP B0 active dead 0 1 3078 pci@8/SUNW,qlc@2 c5t500601603B207225d0s0 SP A0 active dead 0 1 3078 pci@8/SUNW,qlc@2 c5t5006016A3B207225d0s0 SP B2 active dead 0 1

Il fallait donc nettoyer tout ça et recréer le device proprement :

# powermt check Warning: CLARiiON device path c3t500601623B207225d0s0 is currently dead. Do you want to remove it (y/n/a/q)? a Warning: CLARiiON device path c3t500601683B207225d0s0 is currently dead. Warning: CLARiiON device path c5t500601603B207225d0s0 is currently dead. Warning: CLARiiON device path c5t5006016A3B207225d0s0 is currently dead. # powercf -q Could not validate the entry: --------------------------------------- emcpower77: user ID = fd00000268 --------------------------------------- removing emcpower77 # powermt config # powermt display dev=emcpower77c Pseudo name=emcpower77a CLARiiON ID=CKM00104900008 [cesena] Logical device ID=6006016069F02A000C1FADD01186E011 [TRANSFERT_BI] state=alive; policy=CLAROpt; priority=0; queued-IOs=0 Owner: default=SP B, current=SP B ============================================================================== ---------------- Host --------------- - Stor - -- I/O Path - -- Stats --- ### HW Path I/O Paths Interf. Mode State Q-IOs Errors ============================================================================== 3077 pci@8/SUNW,qlc@1 c3t500601623B207225d0s0 SP A2 active alive 0 0 3077 pci@8/SUNW,qlc@1 c3t500601683B207225d0s0 SP B0 active alive 0 0 3078 pci@8/SUNW,qlc@2 c5t500601603B207225d0s0 SP A0 active alive 0 0 3078 pci@8/SUNW,qlc@2 c5t5006016A3B207225d0s0 SP B2 active alive 0 0

Et voilà, notre nouvelle LUN est bien détectée.

82 Comments »

Bien que le noyau Linux supporte nativement les filesystems ufs, la fonction n'est pas présente par défaut sur les RHEL. Voici comment l'activer sur une RHEL 5.5 - le principe sera le même sur d'autres versions, sachant que les versions plus récentes devraient pouvoir s'épargner la mise à jour du module-init-tools.

A cause d'un petit bug, une mise à jour mineure est nécessaire avant l'opération. On va donc télécharger le package module-init-tools-3.3-0.pre3.1.60.el5_5.1.x86_64.rpm chez RedHat  (souscription RHN nécessaire) et le mettre à jour.

# mount -o remount,rw /boot # rpm -Uvh ./module-init-tools-3.3-0.pre3.1.60.el5_5.1.x86_64.rpm Preparing... ########################################### [100%] 1:module-init-tools ########################################### [100%]

On télécharge ensuite le package kmod-ufs correspondant à notre version de RHEL, et on installe.

# rpm -ivh ./kmod-ufs-0.0-1.el5.elrepo.x86_64.rpm warning: ./kmod-ufs-0.0-1.el5.elrepo.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID baadae52 Preparing... ########################################### [100%] 1:kmod-ufs ########################################### [100%] Working. This may take some time ... Done.

Et ça y est, on peut monter un filesystem ufs (dans l'exemple ci-dessous, le filesystem a été créé sur un serveur Sparc, directement dans un fichier) :

# mount -t ufs -o ro,loop,ufstype=sun ./testufs /mnt # cd /mnt /mnt# ls lost+found victory /mnt# cat victory Ca marche.

313 Comments »

Quand on gère un serveur SMTP sortant, il peut arriver que l'on souhaite filtrer totalement les messages émis à destination d'un domaine, tout en donnant l'impression à l'émetteur que le message est bien parti. C'est le cas par exemple quand une plate-forme de test souhaite émettre de nombreux messages pour tester ses capacités d'envoi.

Après avoir essayé différentes approches, la plus élégante à mes yeux est l'utilisation de transport_maps, qui permet de spécifier des relais particuliers en fonction de la destination.

Déclarons tout d'abord un tel fichier dans le main.cf de Postfix :

transport_maps = dbm:/etc/postfix/trounoir_map

Notez ici que l'utilisation de dbm est un choix de portabilité, j'ai déjà eu à faire ce type d'opération sur des versions de Postfix compilées sans pcre, par exemple.

Le fichier en question peut contenir des lignes du type :

exemple.fr     discard:silently

Puisque j'ai spécifié un type dbm, il faut générer les maps à partir du fichier texte :

# postmap -c /etc/postfix /etc/postfix/trounoir_map

Il ne reste plus qu'à redémarrer postfix, et les messages à destination du domaine exemple.fr génèreront des entrées de ce type (notez le discard au début de la ligne et le silently à la fin) :

postfix/discard[3923]: [ID 197553 mail.info] 8E816F5D: to=, relay=none, delay=13, delays=13/0/0/0, dsn=2.0.0, status=sent (silently)

Commentaires fermés sur SMTP sortant : faire un trou noir avec Postfix

Dans un environnement hétérogène, il est possible que tous les serveurs n'utilisent pas la même version de NFS, certains étant encore en v3, d'autres en v4. Pour afficher la version utilisée par un montage spécifique, on peut utiliser la commande nfsstat :

# nfsstat -m /montage /montage from serveur_nfs:/montage Flags: vers=4,proto=tcp,sec=sys,hard,intr,link,symlink,rsize=32768,wsize=32768, retrans=5,timeo=600 Attr cache: acregmin=3,acregmax=60,acdirmin=30,acdirmax=60

Selon les cas, on verra vers=3 ou vers=4.

Cette commande est disponibles sur divers *nix, incluant notamment Solaris et Linux.

86 Comments »

Oracle vient d'annoncer la sortie en 2011 du SPARC SuperCluster, une nouvelle gamme de serveurs complets pour faire tourner, bien entendu, de l'Oracle RAC. S'appuyant sur des processeurs T3, utilisant les extensions SSD Flashfire, et intégrant des boîtes de type ZFS Storage 7420, ces serveurs disposent également d'un switch InfiniBand interne.

Oracle nous propose donc là une bien belle solution rassemblant leurs évolutions techniques les plus intéressantes, et les performances sont au rendez-vous : d'après les benchmarks d'Oracle, le record de transactions par minute (TPM) serait pulvérisé, avec 30 millions de TPM, soit trois fois plus que le record actuellement détenu par une base DB2 sur une plate-forme IBM à base de Power 7. Les spécifications du serveur capable de ces performances ont elles aussi de quoi donner le tournis : 108 processeurs T3 (soit 1728 cores, ou 13 824 threads hardware!), 13 TB de mémoire, 246 TB de stockage SSD, et 1.7 PB de stockage total.

On peut imaginer que le prix de la solution sera en rapport.

Commentaires fermés sur SPARC SuperCluster