Google I/O
Huit jours avant la conférence annuelle Google I/O, qui se tiendra les 25 et 26 juin 2014 à San Francisco, Californie, Google annonce deux nouvelles options en préversions pour sa plate-forme Cloud : le stockage SSD et la répartition de charge HTTP.
Le nombre de testeurs de la préversion est limité. Il faut s’inscrire ici pour tester le stockage SSD et là pour tester la répartition de charge HTTP.
Stockage Cloud
Les clients qui ont besoin de performances disques de haut niveau peuvent choisir l’option SSD pour le stockage persistant au prix en Europe de 0,325 $ (environ 0,240 €) par gigaoctet. C’est 12,5 fois plus cher que le stockage sur disque standard.
La comparaison avec Amazon, qui offre du SSD depuis longtemps sur son service Elastic Block Store, est difficile. Le gigaoctet coûte entre 0,11 $ et 0,138 $ en fonction du provisionnement ou non d’IOPS (entrées-sorties par seconde). Auquel il faut ajouter un coût variable en fonction du nombre d’IOPS à 0,11 $ par IOPS provisionné par mois.
Si Microsoft Azure utilise partiellement les SSD pour l’Azure Blob storage, le nombre d’IOPS serait limité à 500 par disque virtuel. Il serait possible de les multiplier pour augmenter les IOPS.
Notons que l’un des derniers entrants, Digital Ocean, utilise exclusivement du SSD dans ses offres.
Google garantirait 30 IOPS par gigaoctet pour son stockage SSD, contre 0,3 en lecture et 1,5 en écriture sur un disque dur traditionnel:
| Par Gigaoctet | Disque dur | SSD | Amélioration |
| IOPS Lecture max |
0,3 |
30 | x 100 |
| IOPS écriture max |
1,5 |
30 |
x 20 |
| Débit lecture (Mo/s) |
0,12 |
0,48 |
x 4 |
|
Débit écriture (Mo/s) |
0,09 | 0,48 |
x 5,3 |
Répartition de charge HTTP
D’après Google, la répartition de charge HTTP permettrait de pouvoir répondre à plus d’un million de requêtes par seconde sans phase préparatoire.
Il est possible de répartir la charge en fonction du contenu.
Et grande nouveauté, il est possible de répartir la charge à travers toutes les régions, ce que n’offre par exemple pas AWS, qui ne propose la répartition que dans une ou plusieurs zones de disponibilité d’une même région.
En revanche, il n’est pas possible d’utiliser le protocole SSL pour la répartition de charge, contrairement à AWS Elastic Load Balancing.
La répartition de charge de Microsoft Azure est une répartition de charge au niveau de la couche 4 du modèle OSI, la couche de transport.