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é.