Oracle SPARC Showcase 2013

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)

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

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 :

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.

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.

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 :

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.