Livraison 26 Octobre 2008

[oles@ovh.net]

Bonjour,
Voici l'état de livraison à 2008-10-26 23h00.

Quand il y a un retard, il faut lire:
"la plus ancienne commande payée et non réalisée a XX heures de retard"

Real Private Server
- RPS 1 12H de retard (2008-10-26 16:00:14)
- RPS 2 OK -> 1 heure
- RPS 3 OK -> 1 heure

Serveurs pour découvrir et de jeux:
- Kimsufi L OK -> 1 heure
- Kimsufi XL 12H de retard (2008-10-26 05:01:41)
- Kimsufi 2XL OK -> 1 heure
- Kimsufi 3XL OK -> 1 heure
- Kimsufi 4XL OK -> 1 heure

Serveurs d'entreprise, professionnels et critique:
- miniSP OK -> 1 heure
- SP bestof OK -> 1 heure
- SP Max fr,es OK -> 1 heure
- SP Max de OK -> 1 heure
- SP Max uk,pl OK -> 1 heure

- EG Bestof 12H de retard (2008-10-26 05:12:04)
- EG Max OK -> 1 heure
- EG Large OK -> 1 heure
- EG SSD OK -> 1 heure

- MG Bestof OK -> 1 heure
- MG Max OK -> 1 heure
- MG Large OK -> 1 heure
- MG SSD OK -> 1 heure
- MG X Large OK -> 1 heure

- miniHG OK -> 1 heure
- HG Bestof 3J de retard (2008-10-23 20:02:10)
- HG BiTurbo 3J de retard (2008-10-23 17:53:03)
- HG Large 7J de retard (2008-10-16 21:01:05)


Les livraisons de RPS n'ont pas été très régulières cette semaine. Nous
connaissons une croissance assez violente des commandes depuis 2 semaines
et nous avons encore du mal à savoir combien de nouveaux RPS doivent
être fabriqués par semaine. Aussi, le système actuel de livraison de RPS
n'est pas prévu pour livrer plus de 100 RPS / jour, à cause du "non parallélisme"
des opérations sur les infrastructures de stockage. Nous changeons donc des
méthodes de travail et sous quelques jours on devrait finaliser l'industrialisation
des processes concernant les RPS. Le but est de ne pas afficher le nombre des
RPS disponibles mais d'avoir toujours le stock nécessaire et livrer tous
les clients, quelque soit la quantité en 1 heure. C'est le contrat.

Les livraisons de Kimsufi et PRO se font sans problème, sauf pour le HG.
Comme déjà annoncé, nous prévoyons la mise en place d'une nouvelle gamme HG 2009
courant de la semaine, maximum 10 jours et la production a été réorientée
déjà vers les nouveaux serveurs bientôt disponibles en 1 heure. Nous
travaillons sur le site et le moteur des options. En effet, on souhaite vous
proposer un serveur extrement puissant, très stable et totalement personalisable.
Sous 10 jours maximum, on aura la réponse si nous allons dans la bonne direction.

Cette semaine, nous avons finalisé 90% de la backbone Européen d'Ovh. Nous sommes
présents sur l'Espanix à Madrid avec 2x10G, sur le MIX à Milan avec 1x10G, sur le
VIX à Vienne avec 1x10G, sur NIX à Prague avec 1x10G et nous établissons les
premiers peering avec les autres réseaux présents sur ces points de peering et
qui souhaitent échanger le trafic avec Ovh. Cette semaine nous démarrons le TIX
et SwissIX à Zurick puis ça sera le tour de Varsovie (un peu compliqué mais on
va y arriver). Vous pouvez voir notre réseau en temps réel sur le weathermap
http://weathermap.ovh.net/europe
Il s'agit de la backbone basés sur les 10G. Pour ceux qui aiment bien se prendre
la tête, il y a une version complète avec tous les liens input/output d'Ovh:
http://weathermap.ovh.net/backbone
Aujourd'hui, nous avons équilibré le trafic entre toutes les villes afin que
le réseau soit optimisé. Le trafic entre Roubaix et Milan, passe maintenant
correctement Roubaix-Paris-Frankfurt-Zurick-Milan au lieu de Roubaix-Paris-Madrid-Milan
et au finale un gain 30ms. De même, le trafic de Vienne vers Paris, passe par
Prague-Frankfurt et non plus par Milan-Zurick-Frankfurt.

Il nous reste quelques problèmes à résoudre sur la backbone:
- http://travaux.ovh.com/?do=details&id=2547
Nous allons ajouter un 10G entre le routeur et le switch qui gère les
interconnexions Decix. Le xenpack va arriver demain à Frankfurt et sera
mis en place dans la foulée.
- http://travaux.ovh.com/?do=details&id=2534
Nous avons un problème totalement étrange sur Linx 224. Le débit de certains
clients vers certains réseaux avec qui ont échange le trafic sur Linx 224,
ne se fait pas à pleine vitesse. D'après les tests effectués avec certains
clients, nous avons isolé Linx 224, mais d'après Linx il n'y a aucun problème
de saturation interne sur Linx. Nous allons donc changer toutes les jarretières
en fibre optique sur toute notre infrastructure de Londrès. Même s'il n'y a
aucune perte de packet, il y a quelque chose quelque part. Il faut commencer
donc quelque part.
http://weathermap.ovh.net/london
- http://travaux.ovh.com/?do=details&id=2492
un switch doit être mis en place à Bruxelles/Interxion puis un 10G connecté
entre le routeur de Bruxelles et Roubaix afin de garantir une meilleure
redondance. On devrait le réaliser dans la semaine.

Avec l'arrivée de ce réseau, nous sommes très proche de démarrage de ChtiX.eu avec
les offres de VLAN entre tous les sites où nous sommes présents et tous les points
de peerings où nous sommes présents. Ainsi, avoir 100Mbps entre Paris et Vienne
c'est 100Euro HT/mois ! De même les offres de transit 100Mbps = 100Euro / mois en
full BGP. Une offre unique disponible partout en Europe.

Certains clients PL et UK nous ont remontés un bug sur la bande passante interne
sur notre réseau. Une partie de ce problème est résolu mais pas tout. Nous avons
en effet beaucoup des équipements réseau différents et il faut adapter le setup
pour chaque éléments, tout en étant sûr qu'il produit le même effet. Nous nous
sommes rendus compte que suivant l'équipement les paramètres doivent être
différents pour au final avoir la même chose. Voilà l'origine du problème. On
espère qu'on fixera tous ces problèmes dans la semaine (il faut beaucoup de temps
pour tout tester pour voir le résultat en temps réel et sur les graphes MRTG/RRD).
http://travaux.ovh.com/?do=details&id=2495

Avec l'arrivée de la backbone Est/Sud-Est, le trafic via le Frankfurt va augmenter
dans les semaines à venir. En effet, Prague, Vienne, Zurick et Milan passent par
Frankfurt. Nous allons donc démarrer les travaux de la création de la backbone en
propre à 100Gbps entre Bruxelles et Frankfurt. Ces travaux vont prendre entre 4 et
6 mois. On devrait donc en profiter pleinement à partir de Février/Mars.

Toutes ces démarches et ces investissement concernant le réseau ont un but précis:
améliorer l'accès de tous les visiteurs European sur notre infrastructure. Il
faut trouver le moyens que par exemple un visiteur de CZ puisse consulter vos
sites plus rapidement et puisse échanger le trafic avec vos sites plus rapidement.
Le but n'est donc pas de bâtir le plus gros réseau du monde, mais d'aller vers
les visiteurs au plus proche d'eux là où ils vivent et transporter sur notre
réseau tout le trafic. De cette manière uniquement, on pourra garantir les temps
d'accès et les débits, tout en sachant que malgré tout 100km vont générer 1ms de
temps d'accès en plus et donc on ne va pas créer de trou noir du cosmos pour
faire arriver les packets autrement vers Ovh. Si on regarde les résultats de cette
stratégie on peut aussi s'interroger sur le sens de toutes ces démarches. Prenons
exemples: un peering établit il y a 30 minutes avec un grand réseau en CZ. Nous
avons eu le peering sur Amsix (Amsterdam) et nous l'avons maintenant sur NIX (Prague).
Le résultat un gain de 4ms. 4ms ... c'est quoi 4ms dans nos vies ?

64 bytes from 195.113.144.244: icmp_seq=6 ttl=58 time=21.2 ms
64 bytes from 195.113.144.244: icmp_seq=7 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=8 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=9 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=10 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=11 ttl=58 time=17.6 ms
64 bytes from 195.113.144.244: icmp_seq=12 ttl=58 time=17.5 ms
64 bytes from 195.113.144.244: icmp_seq=13 ttl=58 time=17.7 ms
64 bytes from 195.113.144.244: icmp_seq=14 ttl=58 time=17.6 ms

Hmmm ... 4 ms c'est un accès meilleur de 20% vers l'un de réseau le plus important
en Tchèquie. Est-ce que ça vaut le coup d'investir pour améliorer de 20% les accès
à notre réseau ? Nous n'avons pas de réponse à cette question. En tout cas on pense
que le client lui verra l'intérêt d'utiliser les services d'un hébergeur qui propose
des meilleurs connexions possible en Europe et travaillent constamment sur l'amélioration
son réseau dans le but d'anticiper les besoins de ses clients. On ne sait pas de
quoi est fait demain et il est difficile de prévoir si ceci vous sera ou pas utile.
En tout cas, si demain vous avez des projets en France, en Allemagne, en Pologne ou
Tchèquie et vous avez besoins d'une connexion de qualité, vous savez où taper.

Amicalement
Octave

[oles@ovh.net]

Bonjour,
Il y a quelques années, nous avons mis en place les protections
de serveurs de nos clients contre les attaques venant de l'Internet.
Nous nous sommes concentrés sur les grosses attaques de 500Mbps,
1Gbps ou 4Gbps venant de plusieurs centaines, milliers de serveurs
en destination d'un serveur hébergé chez Ovh. Ce genre d'attaque
ne posait pas de problème sur les routeurs (nous avons beaucoup
de capacité entre Internet et Ovh). Par contre lorsque l'attaque
n'était pas correctement filtrée, le problème apparaissait dans
la baie du serveur victime et donc sur 40/50 serveurs voisins.

Il y a 2-3 ans, dans 99% de cas, il s'agissait de guerres entre les
bandes de hackeurs. L'une de bandes a décidé d'attaquer un serveur
dédié qui hébergé le bot IRC d'une autre bande pour récupérer
l'accès à un channel IRC et il se trouvait que le bot IRC était
hébergé chez Ovh sur un serveur dédié. Et donc lorsqu'une attaque
a été reçue sur un serveur dédié, le serveur a été suspendu et
le contrat cassé.

Depuis la mise en place de filtrage IRC (avec déblocage manuel
par le client dans le manager), et la mise en place de protection
INPUT/OUTPUT (http://travaux.ovh.com/?do=details&id=1421), nous
avons vécu un temps calme et heureux. Ceci marche très bien, car
comme décrit dans le task 1421, nous avons eu une protection par
connexion (100Mbps puis au bout de 32Mo, la connexion passe à 10Mbps)
sans aucune limitation sur la somme de toutes les connexions.
Si quelqu'un attaquait un serveur, son attaque était rapidement
limité à 10Mbps. Et 10Mbps dans pas mal de cas, n'est pas un
problème.

Aujourd'hui, nous souhaitons gérer les petites attaques de 1Mbps,
10Mbps ou 20Mbps. Ce genre d'attaque sont souvent invisibles
pour Ovh puisque notre réseau a une capacité de 400Gbps. On
ne voit pas une attaque de 1Mbps. Or ce genre de petites attaques
sont très dure à gérer pour nos clients. Souvent malgré le
peu de Mbps reçu, le client ne peut plus se connecter sur le
serveur et bloquer l'attaque sur le serveur directement. Et
même s'il arrive, il suffit d'augmenter l'attaque de 20Mbps
à 80Mbps pour que le client perde à nouveau le contrôle du
serveur.

Nous avons mis au point 4 types de protections que le client
peut ou pas activer pour protéger son serveur. Ces protections
doivent maintenant être testés avec certains d'entre vous afin
d'affiner les réglages au besoins réels de nos clients.

4 protections:
- pas de protection du tout:
le client souhaite profiter au maximum de la bande passante
qu'Ovh lui propose. Nous avons enlevé la protection du task
1421 (en bêta test).
- protection WWW:
Si le client a une activité WWW avec les sites Internet
Web 2.0, il peut profiter d'une protection active de son
serveur contre les attaques. Il s'agit de limites la bande
passante entre Internet et le serveur du client, IP par IP
et gérer cette bande passante de chaque IP de l'Internet
vers le serveur. Les visiteurs profitent pleinement des
sites et il n'y a aucune dégradation du service. Par contre
on ne peut pas utiliser le serveur pour les backups ou
transfert de gros fichiers de l'Internet vers le serveur.
Les routeurs bloquent automatiquement ce genre "d'attaque".
Si le client souhaite utiliser le serveur comme le backup,
il suffit de prendre une IP fail-over, accrocher sur le
serveur et ne pas la protéger contre les attaques. Ainsi,
l'activité principale du serveur se basant sur l'IP du
serveur est protégé et sur l'IP fail-over, le client peut
mettre les activités qui nécessitent beaucoup de bande
passante entrante.
- protection GAME:
On voit de plus en plus souvent de petites attaques entre
les joueurs qui attaquent un autre joueur pour le retarder
dans le jeux et gagner la partie ... Nous avons mis au point
une protection spécialement conçue pour les serveurs de jeux.
Mais il faut encore l'affiner.
- protection TOTALE:
si un serveur reçu une attaque importante, nos équipes doivent
intervenir sur le réseau et bloquer l'attaque de manière
rapide et efficace. Cette protection est uniquement destiné
à l'utilisation interne. Une fois la protection mise, le
serveur fonctionne correctement et le client a un total
contrôle sur le serveur. Par contre, il ne peut rien transférer
sur le serveur. Dés qu'il y a trop de packets venant de l'Internet
vers le serveur, les routeurs protègent l'infrastructure d'Ovh.

Ces protections seront rapidement disponibles dans le manager
et activable avec un simple clic.

En attendant, on cherche les bêtas testeurs pour la protection WWW
et GAME. N'hésitez pas m'écrire sur oles@ovh.net en donnant votre
identifiant (-OVH) et l'IP de votre serveur. Si vous voyez d'autres
types de protections à développer, merci de nous faire part de
vos expériences.

Amicalement
Octave