Admins

Le 20/09/2021 sur IRC#april-admin :

16:38 < QGuLL> https://www.scaleway.com/fr/dedibox/pro/pro-2-m-sata/ c'est exactement la même chose que notre pro-3-s mais en plus cher j'ai l'impression
17:02 < benj> QGuLL: un truc du genre
18:00 < cpm_screen> benj: QGuLL: https://www.hetzner.com/dedicated-rootserver/ex42
18:01 < cpm_screen> et se pose la question de passer en ssd
18:01 < cpm_screen> mais bon, c'est pour 2022…

https://pad.april.org/p/migration-host-virola-calamus-2021#L89

Première réunion avec plan d'action suivant : demander à ikoula et scaleway ce qu'ils ont comme proposition.
Suivant les résultats, on avisera sur la machine.

Demander des conseils techniques sur la migration DRBD

Demande DRBD faite :

Bonjour,

Online nous a prévenu qu'on allait devoir migrer nos 2 hosts à l'April, ils sont reliés entre eux par un montage DRBD qui héberge les volumineux qcow de nos VMs libvirt.

On a commencé à réfléchir à la procédure qu'on allait mettre en place, on pensait notamment déconnecter les secondary, monter les nouveaux hôtes en secondary, laisser la synchro se faire, et basculer quand c'est à jour. Avec un tunnel ssh pour sécuriser le flux réseau.
Il y a peut être aussi la possibilité de mettre 2 secondary, on travaille avec du DRBD 9.5 qui semble proposer ça.

Est-ce que vous auriez des avis/conseils techniques sur une telle démarche ?

Librement,
Quentin (QGuLL) pour l'équipe adminsys April.

réponse de brenard d'easter-eggs :

Bonjour,

Effectivement, la solution changer/ajouter les nouvelles machines en slave sera certainement la solution la plus pertinente pour une migration en douceur. Attention cependant à modifier temporairement la synchronisation en asynchrone : en effet, sans cela, la performance des accès en écriture aux disques des VMs sera fortement perturbée. Pour cela, il faut changer de protocole de réplication : vous devez actuellement être en C et il faudra passer en A :

https://linbit.com/drbd-user-guide/drbd-guide-9_0-en/#s-replication-protocols

Concernant l'ajout d'un nouveau slave, plutôt que le remplacement de celui existant, c'est une option, mais elle peut s'avérer un peu plus complexe. Il faut en effet par défaut que tous les nœuds puissent communiquer ensemble. Ici, à coup de tunnel SSH, ça risque d'être un peu compliqué. Il vaudrait mieux, je pense, partir sur des tunnels OpenVPN chiffrés qui seront plus performants et plus stables. Une fois les tunnels en place entre les nœuds actuels et les nouveaux, vous pourrez ajouter des connexions entre les machines dans la conf DRBD, tout en conservant la connexion directe entre les machines existantes :

https://linbit.com/drbd-user-guide/drbd-guide-9_0-en/#s-drbdconf-conns

Bon courage pour cette migration.

Librement,

Demande à scaleway faite via ticket 1042278 :

Bonjour,
Le 20 septembre vous nous avez fait parvenir un mail concernant le décommissionnement à venir (février/avril 2022) de 2 de nos serveurs de la gamme Dedibox LT 2015 :
81050 - Pro-3-S - virola
81104 - Pro-3-S - calamus

Vous nous avez invité à regarder la gamme actuelle pour trouver des serveurs de remplacement, mais nous n'en avons pas trouvé. Nous demandons donc des conseils commerciaux pour avoir 2 serveurs qui remplissent la même fonction, ils doivent répondre au besoin suivant :

CPU au minimum équivalent au Xéon E3-1231v3 avec instructions matérielles KVM
32 minimum de ram
2 interfaces réseau, RPN disponible entre les deux serveurs (ou équivalent)
2*2To minimum de disque
IP failover attachables à l'un ou l'autre serveur
Tarif dans la gamme de prix actuelle

Cordialement,
l'équipe adminsys de l'April.

Réponse de forward :

<pre>
Bonjour,

Je transmets ce ticket à l'équipe concernée, nous revenons vers vous. 

Cordialement,

Benjamin Lussignol
-----
Customer Excellence Team 
</pre>

réponse de scaleway/online :

Bonjour Frédéric,

Concernant les différentes solutions que Scaleway peut vous proposer, à ce jour nous n'avons pas d'offre vraiment équivalente, surtout dans la même gamme de prix de votre serveur commandé il y a 6 ans.
Tout d'abord je tiens à vous rappeler que nous attendons le déploiement d'une nouvelle génération de serveurs dédiés super-compétitifs en janvier.
Si vous ne souhaitez pas attendre le mois de janvier, je vous invite à trouver ci-dessous nos recommandations de migration :

Choisir des serveurs dédiés disponibles à ce jour dans notre catalogue publique (https://www.scaleway.com/fr/dedibox/tarifs/). Notre nouvelle génération de serveurs dédiés, par exemple, apporte avec elle beaucoup de technologie et de nouvelles options, comme l'option de bande passante supplémentaire (https://www.scaleway.com/fr/dedibox/reseau/bande-passante/). Ces machines sont également compatibles avec l'option de disques locaux supplémentaires (https://www.scaleway.com/fr/dedibox/stockage/disques-locaux/).

Afin de répondre à votre besoin pour deux interfaces réseaux, je vous informe que cette option est disponible dans toutes nos gammes sauf la Start.
Veuillez noter que l’accès à notre réseau privé vous donne également la possibilité d'ajouter un stockage SAN à vos serveurs, notre solution RPN-SAN (https://www.scaleway.com/fr/dedibox/stockage/rpn-san/), dans laquelle les performances I/O sont aussi limitées par la bande passante du réseau privé RPN (https://www.scaleway.com/fr/dedibox/reseau-prive-rpn/) de votre serveur dédié et sont susceptibles d'être augmentées avec le Business Service Level (https://www.scaleway.com/fr/dedibox/services-basique-et-business/) en option.

Une autre solution serait de déplacer cette partie de votre infrastructure vers notre complète écosystème cloud Scaleway Elements (http://scaleway.com/fr/elements/). Vous pouvez avoir des machines virtuelles (https://www.scaleway.com/fr/instances-virtuelles/) avec autant de Block Storage (https://www.scaleway.com/fr/block-storage/) que vous souhaitez, utiliser notre solution Object Storage (https://www.scaleway.com/fr/object-storage/) basée sur le protocole S3, nos bases de données managées SQL (https://www.scaleway.com/fr/database/) et encore plus (https://www.scaleway.com/fr/tarifs/).

Je reste dans l'attente de votre retour avec votre plan de migration afin de vous proposer un dédommagement sur les frais de migration.

Je reste à votre disposition pour tout complément d'information.
Cordialement,

Victor Herrera
Sales Account Manager
Scaleway

Réponse donnée à scaleway :

Bonjour,

Les délais imposés avant la coupure des serveurs actuels ne nous permettent pas d'attendre le mois de janvier et la nouvelle offre de serveurs dédiés super-compétitifs, d'un point de vue prise de décision et organisation des migrations : dès le mois de février les pannes ne seront plus réparées.

Les autres solutions ne répondent pas à notre problématique.

Cordialement

réponse à la réponse :

Bonjour Frédéric,

Merci pour votre retour avec ces précisions; je vous comprends.
Dans le cas où vous décidez de partir vers un autre serveur dédié Scaleway Dedibox, n'hésitez pas à nous recontacter par ticekt avec votre plan de migration.
Nous serons en mésure de vous offrir les frais d'installation + le premier mois offer sur les machines remplaçantes afin d'éviter la double facturation.

Nous restons à votre disposition.
Cordialement,

Victor Herrera
Sales Account Manager
Scaleway

Prise de décision hier : 2*AX41
Mail envoyé à Hetzner pour confirmer la faisabilité :

Hi,

We would like to take 2 additional servers ax41.
Is that possible to have them both next to each other with a second network interface connected directly one to the other (like you have done for the two EX41 we ordered several years ago).
Is there any additional option to take to add one additionnal IP Failover to one on the two servers ?

Is it possible to add another SATA 2Tb disc on the server in several months/years, for what cost ?

Lastly, what would it cost monthly and for the installation to order :
 - two AX41 hosted in germany with one additional ethernet interface linked directly one to the other
 - one IP Failover

Thanks

Réponse des allemands :

Dear Mr Francois

An internal lan between two AX41 servers is possible.
Please find following a non binding quote.

Setup costs:
2x Server AX41 (€ 39.00)           € 78.00
Failover IP                        € 19.00
---
Total setup costs:                 € 97.00

Monthly costs:
2x Server AX41 (€ 39.00)           € 78.00
2x 1 Gbit LAN connection  (€ 1.00)  € 2.00
2x 1 Gbit NIC (€ 2.00)              € 4.00
Failover IP                         € 4.20
---
Total monthly costs:               € 88.20

(excl. VAT)

It would be possible to add one additional Sata HDD to an AX41 server. You find the disks that we offer an prices here.

Best regards

  Ralf Sager

Sales

Hetzner Online GmbH

Commande faite

Virola2 et Calamus2 sont sync et branchés sur virola et calamus, il reste la bascule à faire :
TODO :
* configurer l'IP Failover sur virola2 (robot hetzner, conf résal, parefeu) DONE
* basculer les entrées DNS de l'ancienne ip failover à la nouvelle DONE
* arrêter les vm sur virola et calamus DONE
* déconnecter les drbd virola et calamus sur virola et calamus (drbdadm disconnect virola, drbdadm disconnect calamus) + passage en secondary DONE
* passage en primary virola sur virola2 et calamus sur calamus2 DONE
* configurer virola.res et calamus.res dans /etc/drbd/ avec les IP internes (172.16.0.252 et 172.16.0.251) + effacer protocol A DONE
* adapter le parefeu et mettre les bons "MY_REMOTE" DONE
* connecter virola sur calamus2 et calamus sur virola2, laisser sync en arrière plan (voir https://agir.april.org/issues/5638#note-12 pour initialisation des secondary /!\ ne pas se tromper d'hôte sinon effacement des données) DONE
* mounter virola sur virola2 et calamus sur calamus2 DONE
* essayer de démarrer les VMs DONE
* restaurer le /etc/hosts des hôtes DONE
* adapter la doc de reboot, bascule DONE
* renommer en virola-old et calamus-old virola et calamus et les arrêter DONE
* renommer virola2 et calamus2 en virola et calamus DONE
* faire des derniers rgrep de calamus2 et virola2 dans /etc, /srv/common DONE
* faire des derniers rgrep de l'ancienne IPFO dans /etc, /srv/common DONE
* vérifier que virola et calamus (nouveaux) sont monitorés DONE

La bascule est programmée le week-end des 20 et 21 novembre 2021.

+ ajouter en amont un glue record pour la nouvelle vip chez le registrar
+ mettre à jour l'entrée NS dans le NS

madix    pour l'annonce de la migration, liste-infos@ a été fait, j'ai mis une actu, j'ai fait les gazous et pouets
        pour la prochaine cela pourrait être pas mal d'avoir juste une page web indiquant la migration en cours, ailleurs que sur le SI sur laquelle on renverrait tous les accès à nos services web notamment, je ne mesure pas la difficulté du truc
madix:  on peut encore le faire je pense
madix    si c'est faisable ce serait bien, je n'ai aucune idée de la façon de faire dans notre contexte
PoluX_    la difficulté c'est tls
        le plus simple c'est peut être de faire une copie de bastion et de le laisser écouter sur vip jusqu'au moment ou on sait qu'en basculant vip dans le dns on recouvre nos services
madix    après, c'était une suggestion pour le prochain coup, vous rajoutez pas du boulot qui prend du temps et de l'énergie
PoluX_    beh la difficulté vient du fait que l'archi n'est pas prévue pour ; autrement ce serait une « formalité » ; mais la prochaine fois l'archi ne sera pas plus prévue pour :)
        mais en vrai ça ne me semble pas très compliqué comme manip

+ mettre à jour les acl bind pour tenir compte de la nouvelle IP

Il faudra penser aussi à lancer un backup hyperviseur et vm pour voir la réponse de backuppc. (fait)

Erreur lorsqu'on s'identifie sur www.april.org :

user warning: Table './drupal6/watchdog' is marked as crashed and last (automatic?) repair failed query: INSERT INTO watchdog 

Correction, sur connecter sur la VM Drupal, puis mysql :

mysql> repair table watchdog ;

Cela prend 5 minutes.

Suite au signalement d'Isa :

efrei-net.mail.protection.outlook.com[104.47.5.36] said: 550 5.7.606 Access denied, banned sending IP [176.9.141.91]

François a rempli le formulaire pour supprimer notre IP.

J'ai aussi checké notre IP sur http://www.anti-abuse.org/multi-rbl-check-results/?host=176.9.141.91 a priori ça semble ok.