Il y a quelques temps, un client nous a demandé de consolider plusieurs de ses instances, disséminées sur plusieurs serveurs physiques Linux x86, vers des clusters Oracle RAC aussi sur Linux.
Dans la migration, il nous a soumis son souhait de consolider certains schémas afin d’avoir des indexes communs pour des tables hier distribuées sur plusieurs instances. Grâce à cette nouvelle architecture, il voulait bénéficier de la redondance apportée par RAC ainsi que du Scale Out mémoire sur ces nouveaux clusters.

La problématique stockage que nous avons rencontré est celle-ci : tous ses serveurs actuels embarquent des disques flash. Les performances sont excellentes et le client ne souhaite pas dégrader les performances en passant sur un SAN, même full flash. Les abaques sont ceux-ci :

• 100µs < Opérations normales < 750µs
• 750µs < Production dégradée < 1ms
• 1 ms < Arrêt de production

En voyant ces chiffres on comprend aisément la difficulté du problème. La latence nominale de la plupart des baies flash est déjà supérieure à la moitié de la latitude tolérée sur les « Opérations normales ». Ajoutez à cela 200K IOPS avec un ratio de lecture de 70/30 en block size 8-16Ko et plusieurs serveurs en concurrence pour la queue length totale et vous aurez vite du mal à garantir un tel SLA. Par ailleurs, le client demande de pouvoir fournir une bande passante de 10Go/s pour alimenter ses sauvegardes. Les points de contentions à considérer dans une telle architecture, sont les suivants en partant du backend :

• Les disques : la flash répondra à nos besoins. Les solutions telles que le Memristor ou le Xpoint sont malheureusement à ce stade purement spéculatifs.
• Les interfaces d’accès disque : le SAS et le SATA sont aujourd’hui les technologies les plus diffusées. Les premiers tests des technologies NVMe montrent que les gains sur ces futures architectures seront immenses. Mais là aussi, ces technologies n’ont pas encore atteint le stade de maturité propre au marché Entreprise.
• La géométrie de stockage backend : c’est ici qu’un certain nombre d’améliorations sont déjà possibles. Un exemple simple : la réduction du facteur de multiplication des IOs backend entre du RAID 1 et du RAID 5. Ce sont ici la technologie employée et la connaissance de l’architecte stockage qui fera la différence.
• Les contrôleurs de stockage : le nombre grandissant d’acteurs du stockage n’aide pas à la prise de décision en la matière mais pour les vétérans du secteur, la hiérarchie (objective) des baies en la matière est assez vite déterminée. Si un arbitre indépendant peut aider, c’est le test SPC1 qui permettra de définir les technologies éligibles puisque les courbes de latence pendant les montées en charge sont présentées dans les Full Disclosure Reports.
• Les interfaces Front End des contrôleurs : nous atteignons sur ce point la guerre de chapelles iSCSI / NFS / Fibre Channel. Là aussi des technologies innovantes de RDMA par exemple arrivent. Mais pour l’instant les produits disponibles sur le marché sont des CNA / HBAs qui permettent de répondre à l’essentiel du besoin. Nous veillerons tout de même à étudier le nombre ports à mettre à disposition pour accepter les bandes passantes et les queues lengths des serveurs connectés au SAN.
• Les fabrics SAN : si on est en Infiniband ou en SAN FC la question se pose assez peu. Les acteurs fournissent aujourd’hui des switchs offrant des commutations par ASIC de l’ordre de la nano seconde. En revanche si nous dessinons un SAN Ethernet standard, nous serons très vigilants à privilégier des switchs DCB offrants une grande bande passante, des latences de commutation très faibles et une gestion de buffering particulière.
• Les CNA/HBAs : la plupart des cartes présentent aujourd’hui des valeurs brutes de performances qui répondent aux besoins exprimés. On s’attachera plutôt à sélectionner un fournisseur dont les drivers montrent une bonne intégration au système d’exploitation retenu et une surcharge de performance CPU faible quand les performances sont importantes.

Même si les couches suivantes sortent du cadre pur de l’infrastructure des gains substantiels sont néanmoins possibles.

• Le système : dans ces différentes couches traversées, les systèmes offrent des potentiels d’amélioration mais surtout de nuisance. On s’attachera ici à valider la configuration des drivers, du multipathing, du volume manager et du filesystem. Les configurations établies ici ont un impact important sur la résilience et la performance globale de la solution.
• L’applicatif / middleware : on quitte ici totalement le monde de l’infrastructure et nous entrons dans les couches qui nécessitent des modifications importantes. Les plus grands gains possibles sont bien sûr dans ces dernières couches. Quoi de mieux que la requête parfaite pour exploiter au mieux les performances du stockage ? Je suis encore surpris tous les jours de l’imperfection navrante de certains logiciels ou de l’incroyable performance obtenue sur des algorithmes ultra-optimisés développés par nos meilleurs codeurs.

Sur cette dernière question, mon client me garantit qu’il a réfléchit à l’ensemble de sa pile logicielle. Etant donné ce que je connais de son métier et de son équipe IT, je le crois ! Et si vous vous souvenez du début de l’article, il semble bien que ce soit sur cette nouvelle base de code qu’il initie ce projet. Ces approches Top-Down dans l’élaboration des projets d’infrastructure sont véritablement divertissantes. 🙂