Oracle SPARC Showcase 2013

Témoignage Clients

Fabrice BOISSIER

Résumé du Oracle SPARC Showcase du 17 septembre 2013 ayant eu lieu à l'Hôtel Warwick aux Champs-Élysées.

Votre avis et vos suggestions sur cet article m'intéressent ! Alors après votre lecture, n'hésitez pas : Commentez

- Titre : Oracle SPARC Showcase 2013

- Auteur : Fabrice BOISSIER

- Parution : 17 septembre 2013

- Mise à jour : 8 octobre 2013

- Licence : Copyright ® 2013 BOISSIER Fabrice (Metalman). Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- II. Conférence

- II-A. Annonces Oracle

- II-B. Points communs entre clients

- II-C. Client 1

- II-D. Client 2

- II-E. Client 3

- III. Conclusion

- IV. Remerciements

- V. Liens utiles

I - Introduction

Oracle, entreprise célèbre pour son SGBD du même nom, et récemment par le rachat de Sun, a invité ses partenaires et clients à assister aux témoignages de 3 clients sur leurs expériences avec les nouvelles plateformes à base de SPARC T4 et T5.

Oracle n'étant historiquement pas dédiée au hardware nous a démontré par les témoignages de ses clients comment l'ajout de cette branche lui a été très favorable, et comment elle compte continuer à développer les plateformes Solaris/SPARC.

II - Conférence

II-A - Annonces Oracle

Les premières annonces ont été un rappel de la version 12c de Oracle Database, et des prochains SPARC M6. La multiplication par 2 du nombre de cœurs entre les SPARC T4 (8 cœurs entre 2,85 Ghz et 3 Ghz) et T5 (16 cœurs à 3,6 Ghz) a également été montrée, en insistant sur le dépassement technique et le prix beaucoup plus faible face au célèbre POWER7 (8 cœurs entre 3 Ghz et 4,25 Ghz) d'IBM, et de tous les autres RISC du marché, via de nombreux benchmarks. Les principaux gains ont été faits au niveau de la bande passante au sein de chaque serveur (augmentation des performances I/O au sein de chaque serveur physique).

OVM (Oracle VM) a été très appuyé avec les capacités des SR-IOV et des PCIe Direct I/O permettant un accès natif aux I/O par les VM. Le Virtual Networking a été étendu. InfiniBand s'impose sur toutes les machines pour permettre des transferts très rapides. Cette extension permet du coup d'utiliser le « Secure Live Migration » ! Ce système permet de transférer des VM entre plusieurs machines de plusieurs générations (T4/T5/M5) sans difficulté. Il n'y a aucune licence à payer étant donné qu'il s'agit d'un firmware fourni avec toutes les machines. Seule contrainte : il faut que les mêmes firmwares soient présents sur toutes les machines devant échanger des VM. Pas de rétrocompatibilité avec le Secure Live Migration en firmware.

Quelques chiffres ont été présentés pour montrer la puissance des solutions « tout-en-un » Oracle (hardware + software) :

ERP Oracle, 3100 utilisateurs simultanés, deux T5-8, 1 To mémoire (Application + SGBD)

II-B - Points communs entre clients

Les 3 clients ont expliqué les décisions qui les ont poussés à choisir Oracle et ses solutions pour leurs SI. Ces clients sont souvent des clients avec des besoins mid-range en informatique (entre du mainframe et les petits serveurs x86). Les principaux arguments en commun ont été :

- simplifier l'architecture (moins de machines, et plus d'homogénéité) ;

- approcher un cycle de vie de 3 ans par machine (éviter de conserver des machines trop anciennes au delà de l'amortissement) ;

- réduire les coûts.

La réduction des coûts est un besoin « classique » mais qui commence à prendre une autre forme, de plus, c'est devenu une conséquence des deux autres besoins.

La simplification de l'architecture implique maintenant de réduire le nombre de machines pour gagner de l'espace. Moins d'espace signifie moins de baies à louer si le datacenter est mutualisé. L'homogénéisation des machines et OS (100 % Solaris/SPARC avec logiciels Oracle, plutôt que Solaris + AIX) permet de réduire le nombre de compétences nécessaires, donc réduire les formations techniques. Le personnel n'a plus besoin d'être « multi-compétences » pour une même couche. Une réduction du personnel est donc envisageable étant donné l'inutilité des compétences AIX dans certaines situations similaires à l'exemple. Simplifier ainsi signifie également un seul point de support, donc la fin des fournisseurs se renvoyant la faute en cas de problème.

Le cycle de vie « forcé » à 3 ans permettra d'éviter un cas présenté : des Solaris 8, 9 et 10 qui cohabitent sur des machines de diverses générations, sur lesquelles, pour les plus anciennes, surviennent des pannes de plus en plus fréquentes. La migration entraîne à elle seule une simplification « physique » (donc quelques économies), et une réduction du nombre de pannes prévues (donc amélioration du SLA).

II-C - Client 1

Dans le cas du premier client, plusieurs datacenters sont présents dans le monde, cela fait 15 ans que celui-ci travaille avec des SPARC. Suite à une identification d'obsolescence, 50 machines sont considérées comme « trop anciennes » et hors normes.

Les 30 plus anciennes machines dépassent amplement les 3 ans d'âge : modèles 280R (UltraSPARC III, EOL janvier 2005) jusqu'à des T3 (SPARC T3, EOL septembre 2010), soit entre 2 et 64 Go de RAM par machine, il y a environ 410 Go de RAM à remplacer.

La cible consiste en la réduction des coûts de maintenance, la réduction de l'espace d'hébergement, la fiabilisation/simplification, et l'ajustement du cycle de vie et l'amortissement à 3 ans maximum.

Pour cela, deux machines T4-4 en Dual Fabric (avec OVM for SPARC) ont été choisies. Le principal effet de bord a été un gain en disponibilité de par la réduction de la complexité. La migration a été simplifiée au maximum : les T4 ont été découpés en VM accueillant chaque machine physique précédente.

Un ratio précis par LDOM a été choisi :

Exécution

Mémoire

Modèle

4 threads

8 Go

V240 et moins

1 cœur

16 Go

V440

2 cœurs

32 Go

V490/V880

4 cœurs

64 Go

V890/T4-1

En parallèle de la réduction du nombre de machines, un alignement sur Solaris 10 a été effectué. Solaris 10 signe malheureusement la « fin » des logos Sun, mais c'est aussi le premier à être certifié pour fonctionner à l'intérieur d'un LDOM.

Le déploiement de ces deux machines s'est fait en 2 semaines avec des administrateurs déjà habitués aux technologies Oracle, il a fallu « après » accompagner les utilisateurs du SI pour les faire migrer vers la nouvelle plateforme Solaris 10/T4-4. Environ 6 mois ont été nécessaires pour complètement migrer depuis les 30 anciennes machines vers le cluster de 2 nouvelles.

Cette migration a servi d'exemple pour le reste du SI, qui suit petit à petit. Cette première migration effectuée, une deuxième a été réalisée sur le même datacenter pour ajouter deux autres T4-4 en cluster également. Les autres sites migrent eux aussi petit à petit sur un modèle similaire de double clusters contenant 2 à 3 machines T4-4 chacun. La migration de l'ensemble des datacenters est prévue sur deux ans.

Le client a également présenté la raison pour laquelle l'ensemble de son parc sera constitué de T4-4 : après la migration du premier datacenter, les premières machines T5-8 étaient disponibles !

Pour un prix équivalent, il était possible d'acquérir deux T4-4 ou un T5-8. Le choix a été celui de la sécurité/disponibilité : les T4-4 ont déjà été éprouvés par la migration passée et d'autres utilisateurs (tandis que les T5-8 sont totalement neufs), une machine sur une qui tombe en panne, et c'est un gros impact sur le SLA, tandis qu'une machine sur deux « en cluster » (pour défaut physique/électrique/…) est encore rattrapable.

À la fin de cette première présentation, 3 points ont été appuyés :

- Le provisionning des VM/applications a été grandement accéléré.

- La plateforme standard en serveur est Solaris/SPARC (aucun autre OS ne sera sur les serveurs).

- 90 à 100 % du parc sera virtualisé à la fin du projet sur 2 ans.

II-D - Client 2

Le second client s'est présenté avec un contexte différent du premier :

- architecture hétérogène (plusieurs générations de SPARC) ;

- plus de 3000 transactions par jour => les batchs de nuit prennent maintenant plus de temps que ce qui est prévu ;

- mise à jour du progiciel Kondor de la version 2.6 vers la 3.3, nécessitant une mise à jour des machines ;

- SLA « Life Critical » : besoin d'une très haute disponibilité 24h/24 et 7j/7.

La seule contrainte est le prix de cette « optimisation », afin d'avoir évidemment le meilleur ROI.

Une comparaison entre 2 solutions a été réalisée :

1. Solaris/SPARC (+ OVM) avec toute la suite logicielle Oracle ;

2. Red Hat, VMware, x86-64 avec logiciels issus de plusieurs éditeurs.

Dans les deux cas, il est nécessaire de placer Kondor et une base Sybase par dessus.

Les critères de choix ont été présentés comme tels :

- Architecture simplifiée : moins de machines, moins de câbles, moins de logiciels, etc.

- Performances en conditions réelles : les benchmarks « classiques » étant refusés, le client a souhaité des simulations répondant à ses critères.

- Stabilité : une des machines « physiques » SPARC du client possède un uptime de plus de 2600 jours (environ 7 ans).

- Support technique : le moins de « points de support » possibles afin d'éviter que les différents acteurs se renvoient les problèmes (Oracle en propose un seul et unique, contre Intel + VMware + Red Hat).

- Capitaliser les compétences internes : le moins de compétences nécessaires pour faire fonctionner et utiliser le SI (100 % Solaris/SPARC).

- Isolation des environnements virtualisés : le SAN doit pouvoir être utilisé par chaque VM.

- ROI : dépenser le moins possible pour offrir le plus de services possibles.

La solution Oracle a été choisie, précisément des SPARC T5-2 avec 256 Go de mémoire en utilisant des LDOM et aussi des ZONE.

Pourquoi utiliser les ZONE et les LDOM ? Le client a répondu que les LDOM sont capables de proposer plusieurs heures système sur un même châssis, ce qui permet de rejouer des évènements internationaux si nécessaire, tandis que les ZONE permettent une répartition et un partage simplifié des cœurs et de la mémoire en cas de ressources inutilisées.

Avant la mise en place de cette solution, le temps de remise en fonctionnement moyen était de 4 heures, il est maintenant de 10 à 15 minutes (redémarrage, duplication, sauvegarde… des VM).

Techniquement la solution a été déployée en quelques mois sur un tiers des serveurs les plus anciens, le progiciel nécessite un peu plus de temps à migrer car d'autres machines sont en cours d'acquisition grâce aux nouveaux services offerts.

II-E - Client 3

Le troisième client a opté pour la solution « ultime » d'Oracle : le SuperCluster. Pour rappel, le SuperCluster consiste en une baie dont les serveurs sont les plus rapides au monde dans leur catégorie (les SPARC T4 ont été la première génération, les T5 sont la deuxième). Cette machine est annoncée sans aucun SPOF, et avec un temps de maintenance nul. Oracle assure avoir optimisé son SGBD et plusieurs de ses logiciels pour cette machine, afin de la rendre unique et totalement dédiée à ses produits.

Les objectifs techniques de cette migration consistent à :

- augmenter les performances lors des pics d'utilisation ;

- « mieux » fonctionner en temps normal ;

- réduire les coûts d'utilisation.

Les produits proposés avec le SuperCluster sont placés sous forme de couches :

Oracle Exalogic
(Accélération Java/WebLogic)

Oracle Exadata
(Accélération SGBD)

Oracle Enterprise Manager

Oracle VM

Solaris

SPARCServer

Les logiciels « métiers » fonctionnent actuellement sur des Solaris 8 et 9, et sont donc éligibles à une migration vers Solaris 10 ou 11.

Le but de cette migration est en réalité « d'extraire » le SI du client de celui d'une autre entreprise, à cause d'obligations légales, en 2 ans.

La question qui a été proposée est logiquement : « Faut-il acquérir à l'identique et déplacer les machines ? »

Les problèmes amenés par cette question sont les suivants :

- « à l'identique » : Non ! Les machines sont déjà obsolètes.

- « acquérir » : L'entreprise liée au client est elle-même liée à une autre entreprise pour l'infrastructure. En plus des machines, il faudra donc refaire toute l'infrastructure.

Le SI actuel comporte 3 versions différentes de Solaris, et 2 versions d'AIX. Il faut qu'au bout des 2 ans le SI soit totalement extrait (sinon des pénalités légales « peuvent » être subies).

3 objectifs orientés « management » sont aussi visés :

- Maîtrise des coûts : éviter de dépasser les coûts de fonctionnements, d'acquisition et pénaux prévus.

- Maîtrise des risques : garder la main sur le SI (et pas l'inverse : ne pas arriver dans une situation où une machine obsolète doit rester allumée en espérant qu'elle ne tombe pas en panne).

- Préparer l'avenir : gestion du cycle de vie + moins d'OS à gérer.

Le SuperCluster T5-8 vient remplacer 51 serveurs (environ 575 cœurs), et il faudra le lier à deux baies de stockage de 50 To dont la croissance des données entrantes est estimée à +25 % par an.

Cette solution apporte ces réponses aux 3 objectifs managériaux :

1. Maîtrise des coûts :

- un sponsor de haut niveau a permis au client d'obtenir une offre globale contenant l'acquisition des machines, l'acquisition des logiciels, la maintenance, etc.

2. Réduction des risques :

- une stack pré-intégrée au SuperCluster ;

- un seul et unique projet touchant le matériel, le logiciel et l'intégration ;

- 3 acteurs « issus » de l'entreprise avec laquelle le client était lié : Oracle pour la vente et le support, Fujitsu pour le déploiement, Euriware pour l'exploitation ; Fujitsu a accepté de porter le risque de migration des OS ;

- une seule version de Solaris, et aucun autre OS ;

- opération de mise à jour matérielle et logicielle testée préalablement par Oracle ;

- un seul et unique support technique.

3. Préparer l'avenir :

- moins de matériel, et moins de consommation électrique ;

- homogénéité des OS : un seul UNIX ;

- gestion du cycle de vie, avec un seul fournisseur pour les licences et le support ;

- scalabilité ;

- uniformisation de l'exploitation.

Le retour d'expérience explique que l'intégration du SuperCluster n'est pas si facile non plus : la boîte noire que l'on branche et démarre n'existe pas… Il faut évidemment configurer et apporter ses préférences dessus. La supervision n'a pas été abordée et nécessite de l'outillage supplémentaire.

III - Conclusion

Oracle a su tirer le meilleur des architectures SPARC en expliquant « lier » les équipes hardware et software dans leur cycle de développement. Leur avance (tant technique que dans les délais) sur leur roadmap est un signe d'organisation interne de très bonne qualité.

On ne peut s'attendre qu'à de grands progrès en terme de performances sur les prochaines générations, et donc, espérer voir de nouveaux services disponibles sur les prochains logiciels pour analyser des données plus complexes dans ces SI (via de nouvelles méthodes de data mining, etc.).

Les clients présents visent une réduction du nombre d'OS sur leurs serveurs afin de réduire le nombre de compétences nécessaires et de fournisseurs, donc les coûts de maintenance. La simplification du SI est également visé en utilisant la voie de la virtualisation : les dizaines d'anciennes machines physiques sont agrégées et fonctionnent à l'intérieur de quelques machines physiques plus modernes.

Mon avis sur cette conférence est qu'Oracle cherche « explicitement » à récupérer le marché des SI mid-range en utilisant des arguments très similaires à ceux d'IBM pour le marché des plus gros SI avec les mainframes (pas de SPOF, pas de temps de maintenance, les machines et processeurs sont les plus rapides au monde, suite logicielle « SGBD + Analyse + Transactions » optimisée pour les machines vendues, etc.), tout en utilisant 3 de ses clients comme témoins du retrait des AIX et des POWER contre des Solaris sur SPARC. Les arguments et benchmarks témoignant l'écrasement du POWER7 par les SPARC T5 est aussi un argument choc. Oracle a récemment annoncé les processeurs M6 qui proposent plus de 32 cœurs et « probablement » des machines pouvant en accueillir plus de 90 simultanément… Cela commence à se rapprocher des plus grosses machines IBM de la génération précédente, et cela confirme en effet la différence de cibles commerciales des deux entreprises qui, finalement, essayent d'homogénéiser les SI de leurs clients les plus fidèles tout en améliorant les performances.

IV - Remerciements

Je remercie Oracle pour m'avoir invité à cet évènement qui m'a beaucoup plu et était très intéressant d'un point de vue Architecture des Systèmes d'Informations et des solutions d'entreprises. Je n'avais aucune idée des avancées que les SPARC avaient faites depuis les UltraSPARC T2, cette conférence m'a agréablement surpris.

Je remercie également Voïvode pour sa relecture et ses corrections.

V - Liens utiles

Oracle

Oracle SuperCluster T5-8

Oracle SPARC Systems