Bref, l'incendie d'OVH fera progresser OVH en interne, c'est certain.

Comme en 2017 ou 2018 ? ^^

Nouveau message d'Oles sur LinkedIn.

SBG1/E > Croix > SBG3

Update April,14 9pm
new 200 servers were shipped to Floor 5 which is now full. Tomorrow, we start filling Floor 3. Step by step. Yes, it’s slow. Real nightmare.

Update April,14 10pm
5 racks are UP (using internal-rescue). We are coding all the scripts to detect and (re)setup the servers in the racks / vRacks. Example: sometimes eth0 is eth1, and eth1 is eth0, depends on the motherboard, the cables. Nightmare.

Update April,15 2pm
First servers are given back to custs. Sorry for delay. It’s a real nightmare. It’s not done, still long journey but the code works. Now, we will be able to speed up

Si les noms des interfaces réseau changent, c'est que les cartes mères ont été remplacées. Je soupçonne que dans ces cas là, seul le disque dur a été conservé. Parce que quand on change la CM, on doit aussi souvent changer le CPU et la RAM.

C'est également intéressant de voir OVH s'occuper de « (re)setup the servers, sometimes eth0 is eth1 ». Quand je lis ça, je comprends qu'OVH s'occupe de booter le serveur sur le disque, et que si le réseau ne monte pas (si le vrack & Internet sont inversés, c'est attendu), décide de repasser en rescue, monter le système de fichier, changer le nom des interfaces dans /etc/network/interfaces (par exemple pour Debian), puis relancer le serveur sur disque. Au vu de la quantité de serveurs, je comprends qu'ils aient pris le temps d'automatiser ce process. Je me demande si le client doit donner son accord ou si OVH le fait « dans tous les cas ». Monter le système de fichier du client, c'est très intrusif (même si OVH a accès physiquement au disque dur).

Ça donne à réfléchir sur ce que loue OVH (et les autres hébergeurs) aux clients. Finalement, OVH ne donne pas vraiment de "garantie" sur le modèle de CPU/CM/RAM. Et l'élément le plus critique pour le client, c'est son disque dur. On voit ici la force d'AWS, qui a décidé de résoudre le problème :
- la seule « garantie » du matériel, c'est un nombre de cœurs CPU, de fréquence minimale et de Go de RAM
- pour les données à persister, c'est disque dur réseau uniquement (EBS)
- pour les données « locales », il y a parfois un disque physique attaché, mais aucune garantie de récupérer les données (en cas de reboot, les données sont conservées, mais pas en cas d'hibernation de l'instance par exemple).

D'ailleurs, en cas d'incendie/perte partielle d'une Availability Zone chez AWS, le process de « restauration » aurait été beaucoup plus simple:
- les disques distants (EBS) sont répliqués à l'intérieur d'une même AZ. Avec de la chance, les réplicas sont éloignés « physiquement », mais c'est peu probable, AWS indique que la réplication est faite « en cas de problème sur un disque ». Donc des EBS auraient été perdus.
- les snapshots des EBS sont stockés sur S3, donc répliqués sur d'autres AZ. Aucune perte des snapshots
- le matériel est disposable et les images disques et l'émulation/virtualisation hardware sont faites pour supporter un changement du hardware physique (modulo sur le nouveau matériel environ une fois par an). AWS aurait donc dû racker du matériel fonctionnel, mais sans se soucier de la configuration du client (sur quoi bute OVH en ce moment).

Le prix des instances « à la demande » aurait été très élevé, pour forcer les clients à ne plus utiliser l'AZ impactée, mais une fois le nouveau hardware en place, les clients auraient été autonomes.

J'espère que ça permettra à OVH d'explorer cette voie du matériel disposable. Leur offre OpenStack aka /cloud était un pas dans cette direction, mais manifestement, tout le monde n'y est pas encore passé.

Je me souviens aussi il y a quelques années sur un dédié multi-proc, un des deux est mort et ça à pris quelques messages au support pour le faire changer... Alors que /proc/cpuinfo était clair, mais bon vu que le serveur pingait ça semblait bon pour le support.

-quand on doit faire de la virtualisation au dessus

Mais l'intérêt de faire de « l'instance à la demande », ça n'est pas justement de ne plus faire de virtualisation ?
Il y a sûrement des cas d'usages, sinon AWS n'aurait pas faire de partenariat avec VMware, mais n'est-ce pas spécifique à de (très) gros clients ?

-pour un serveur mysql qui prend très cher, la virtualisation induit des limitations et pertes de performances.

C'est là où AWS est très fort : pour les cas d'usages qui ne correspondent pas à de l'EC2 "pur", ils proposent des services managés et performants. RDS pour les bases de données, S3 pour le stockage objet, etc.

OVHcloud y arrive, mais continue de vendre du bare-metal. Parfois, je me dit qu'à la place d'OVH, j'aurai investi dans une super solution de disques réseaux, avec une offre comme les offres « bare metal de AWS » :
- le serveur est dédié, c'est du bare-metal
- les données sur le disque réseau sont persistés
- OVH peut continuer à pratiquer des tarifs très concurrentiels (parce que le bare-metal est un métier qu'ils maîtrisent très bien)
- la complexité est moindre que monter une offre "Cloud" complète

Dans le cas d'un incendie comme celui qu'ils ont subi, ils auraient « juste » eu à racker des serveurs neufs, et les clients auraient « juste » eu à lancer des nouvelles instances avec les images disques des snapshots.

C'est là où AWS est très fort : pour les cas d'usages qui ne correspondent pas à de l'EC2 "pur", ils proposent des services managés et performants. RDS pour les bases de données, S3 pour le stockage objet, etc.

Oui mais il y a une contrainte de couts à prendre en compte...
Exemple concret avec un client qui fait des ventes en ligne événementielles avec un  Prestashop qui fait 3500 paniers vendus en quelques minutes, si on doit utiliser des building blocs AWS pour tenir la charge que ça génère on en a pour 5 fois le budget que ça nous coute en le faisant nous même avec des serveurs configurés en direct.

C'est aussi un problème  de vouloir de l'abstraction du hardware à tout prix, plus on s'éloigne et monte dans des solutions" haut niveau d'abstraction" plus le rapport cout/performance diminue.
On arrive avec des délires de startups qui ont des solutions Azure à 10.000€ / mois dont elles sont captives alors qu'il y en aurait  pour 2000€ / mois avec une infra gérée par un prestataire qui sait ce qu'il fait.

C'est aussi une conséquence de cette abstraction qui fait qu'on a des gens qui se sentent couverts parce qu'ils ont choisi l'option backup sans imaginer que ça puisse être dans le même batiment..
alors que pour d'autres c'est une évidence que si il n'est pas écrit backup off-site c'est naturel que ce soit dans le serveur juste à coté.