13 novembre 2015

[Hébergement] Nouvelle offre de Cloud Privé par Evolix

Trois ans après l’offre disruptive du serveur dédié physique couplé au Plan de Reprise ou de Continuité sur machine virtuelle, Evolix vous propose une nouvelle offre innovante permettant d’aboutir à de la très haute disponibilité en conservant souplesse et performance.

Offre Cloud privé Evolix

Cette architecture se base sur un minimum de 2 serveurs physiques hébergés dans des datacenters ou espaces devant disposer d’une excellente latence réseau (du type 0.5 ms) comme l’offre d’hébergement Evolix avec sa présence au sein d’Interxion (Marseille) et de TDF (Aix-en-Provence).

Technologiquement les briques logicielles utilisées restent libres avec Linux KVM, libvirt, LVM/DRBD

kvmbanner-logo3500px-DRBD_logo.svglibvirtLogo

evo_cloudprive

Filesystem distribué activable

Grâce à l’utilisation lvm+DRBD, la possibilité vous sera donnée de disposer de l’ensemble ou d’une partie de vos machines virtuelles (VM) sur les deux hyperviseurs différents et ce en temps réel. Suivant le dimensionnement matériel des hyperviseurs (plusieurs grappes RAID avec des technologies différentes), il est envisageable d’avoir des performances I/O disque ciblées sur certaines VM.
Concrètement pour les machines virtuelles en réplication synchrone entre les 2 hyperviseurs, en cas d’incident matériel grave sur l’un des hyperviseurs, le temps de coupure sera limité au temps de redémarrer la VM sur l’hyperviseur fonctionnel sans aucune perte de donnée !

Souplesse de la virtualisation et possibilités de loadbalancing et répartition de charge

Grâce à cette architecture “Cloud Privé”, vous bénéficiez de toute la flexibilité d’environnements virtualisés pour la partie évolution du dimensionnement de vos serveurs ou encore la rapidité de déployer un nouveau serveur temporaire ou non.
À noter que nous mettons souvent en place sur un tel Cloud Privé, une partie logicielle basée sur HAproxy directement sur les hyperviseurs KVM pour gérer du loadbalancing ou de la répartition de charge comme sur les grosses architectures web.
logo-med

De nombreux clients ont déjà fait confiance à Evolix avec une telle offre de Cloud Privé et accèdent ainsi à moindre frais à la très haute disponibilité.

N’hésitez pas à nous contacter pour en savoir plus !

par sdubois le 13 novembre 2015 à 01:12

21 septembre 2015

Ouverture d’un bureau Evolix au Canada

evolix_erable
Mon dernier article a plus d’un an, il se finit sur une prédiction pour 2024 : « C’est désormais une équipe de 20 personnes réparties entre Marseille/Paris/Montréal, permettant un développement international et une infogérance continue 24h/24. »

Septembre 2015 : Evolix se lance à la conquête du monde en ouvrant un bureau à Montréal au Canada ! Nos bureaux sont situés au cœur du quartier du Plateau, proche du centre-ville et des datacenters Cologix où nous sommes en cours d’installation de nos infrastructures d’hébergement. Dès octobre, on pourra donc proposer la location de serveurs à Montréal ! Grâce au décalage horaire France-Québec, on va également améliorer notre offre de surveillance et support 24h/24 : le pic d’activité du soir des sites e-commerce français (20-23h) pourra être étroitement surveillé par notre équipe technique au Canada, c’est ce qu’on appelle l’infogérance Follow-the-Sun.

J’aime à dire qu’Evolix devient donc une  « petite multinationale » …on exporte notre savoir-faire, on s’ouvre à une nouvelle culture, on s’améliore en permanence tout en gardant bien ancrées nos valeurs : proximité avec nos clients, excellence technique et passion pour notre métier et les Logiciels Libres.

par Gregory Colpart le 21 septembre 2015 à 23:35

10 septembre 2015

How to enlarge your raw disk image

Extending a disk image file (of a KVM guest for example) is a tricky operation, especially if we haven't enough disk space to keep a backup of the image we will working on. So I write a little howto for the next time we have to do this operation.

Prerequisites

First, you need to have the following packages installed: qemu-utils kpartx parted.

Make sure your VM is halted and no processes have opened the file:

# lsof $img

Note: for following commands, I assume $img contains the path to your image file.

Extend the image file

Pretty easy step, you can simply use qemu-img tool:

# qemu-img resize $img +50G
Image resized.

You can mount the image and check that it has the correct size:

# kpartx -v -a $img
add map loop0p1 (254:13): 0 195318207 linear /dev/loop0 63
# fdisk -l /dev/loop0 

Disk /dev/loop0: 214.7 GB, 214748364800 bytes
[...]

Extend the partition

Then, you have to extend the partition. That supposes of course either the disk image contains only one partition (which could be a LVM PV) or the partition you want to extend is at the end of the image.

Before all, backup your partition table:

# sfdisk -d /dev/loop0 >~/loop0.parts

(It could be restored with sfdisk /dev/loop0 <~/loop0.parts).

And remove and recreate the partition using all free space with parted:

# parted /dev/loop0 print
Model:  (file)
Disk /dev/loop0: 215GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size   Type     File system  Flags
 1      32.3kB  100GB  100GB  primary  ext3
..
# parted /dev/loop0 rm 1
# parted /dev/loop0 mkpart primary ext3 32.3kB 215GB
# parted /dev/loop0 print

Remount the image to see her new size:

# kpartx -d $img
loop deleted : /dev/loop0
# kpartx -v -a $img
add map loop0p1 (254:13): 0 419430337 linear /dev/loop0 63

Extend the filesystem

We are almost there, remaining the filesystem. First, this is a good thing to run a fsck before all:

# e2fsck -f /dev/mapper/loop0p1 
e2fsck 1.42.5 (29-Jul-2012)
/dev/mapper/loop0p1: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/loop0p1: 41753/6111232 files (9.1% non-contiguous), 23479003/24414775 blocks

Then, resize the filesystem:

# resize2fs /dev/mapper/loop0p1 
resize2fs 1.42.5 (29-Jul-2012)
Resizing the filesystem on /dev/mapper/loop0p1 to 52428792 (4k) blocks.
The filesystem on /dev/mapper/loop0p1 is now 52428792 blocks long.

It's done! We can check if we see the correct size after mounting the partition:

# mount /dev/mapper/loop0p1 /mnt
# df -h /mnt
Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/loop0p1  197G   89G  109G  45% /mnt
# umount /mnt

Finally, unmount the image:

# kpartx -d $img
loop deleted : /dev/loop0

10 septembre 2015 à 17:04

08 septembre 2015

WordPress 4.3 casse la mise à jour via SSH/SFTP

Si vous avez un WordPress installé dans un hébergement sécurisé, vous utilisez probablement la mise à jour via SSH/SFTP pour effectuer les mises à jour. Seulement depuis WordPress 4.3 ce n’est plus possible à cause d’un bug introduit.

La mise à jour a échoué : La mise à jour ne peut pas être installée parce que nous n’allons pas pouvoir copier certains fichiers. Ce problème est généralement dû à des incohérences dans les permissions de fichiers.

Les développeurs de WordPress ont ajouté dans la version 4.3 une vérification, qui ne se comporte pas comme il faut, apparemment lié au support SSH/SFTP de PHP.

Les développeurs ont déjà réfléchi à une solution, et proposent un workaround.

Pour appliquer ce workaround, télécharger le fichier suivant, et patcher le code de votre WordPress avec. Voici un exemple en ligne de commande.

$ cd /home/monsite/www/wp-admin/includes/
$ wget "https://core.trac.wordpress.org/changeset/33688/trunk/src/wp-admin/includes/class-wp-filesystem-ssh2.php?format=diff&new=33688" -O /tmp/WP_ssh.patch
$ patch -p4 < /tmp/WP_ssh.patch

Vous pouvez aussi éditer le fichier « wp-admin/includes/class-wp-filesystem-ssh2.php », commentez/supprimez les lignes 386 et 387, et ajoutez en dessous « return true ».

public function is_writable($file) {
    //$file = ltrim($file, '/');
    //return is_writable('ssh2.sftp://' . $this->sftp_link . '/' . $file);
    return true;
 }

Vous devriez maintenant pouvoir mettre à jour vos plugins/thèmes.
Le problème sera corrigé avec la version 4.3.1.

par benpro le 08 septembre 2015 à 07:58

28 mai 2015

Play a Vim macro on all opened buffers

Here is a small useful tip, which I use in my daily sysadmin work, when I have a lot of similar configuration files to alter, but my modification is to complex to be scripted with sed/awk.

The perfect example is Apache's vhost configurations in site-enabled/.

Open all files in Vim and start recording your macro (with q) on the first buffer.
Until now I opened the next buffer, replay my macro, then opened the next buffer, replay my macro again, etc…
Pretty boring.

But I discovered recently that you can execute a command on all opened buffers, and particularly a macro. Here is the magic line:

:bufdo execute "normal @a"

Replace a with the name of your macro of course, and don't miss to :write at the end of your macro (or add a | write at the end of the command).

28 mai 2015 à 19:16

27 mai 2015

Get verbose output from an already launched cp/mv/rsync process

This could be a bit obvious for others sysadmins, but I use this trick quite often and it's really helpfull.

Imagine you connect on a server and see a running process (a cronjob for example) doing some file copy operations, running for a while and launched without -v option (or you can't see his stdout).

Or imagine you launched a big cp/mv (from a partition to another)/rsync or whatever, you know it will probably run for a while, but you missed to add the -v option.

No problem, here is how we could get an equivalent with strace:

strace -p $(pidof cp) 2>&1 |grep open

Or for a rm:

strace -p $(pidof rm) 2>&1 |grep unlink

If you want just to see the current file your command is currently on:

lsof -p $(pidof cp)

27 mai 2015 à 19:26