Disques système lents, disques de données rapides

Au fil des ans, j'ai constaté que les gens penchent souvent en faveur d'un stockage de données hautement performant et hautement fiable pour une partition de système d'exploitation, mais optent pour un stockage lent et “économique” pour des banques de données critiques. Je suis stupéfait de la fréquence à laquelle je rencontre ce phénomène et, désormais, avec l'avènement des hyperviseurs, je vois le même comportement se répéter à ce niveau également – aggravant les problèmes préexistants.

Dans bien des systèmes aujourd'hui, nous ne traitons que d'une seule grappe de stockage partagée par tous les composants du système. Dans ces cas, nous ne sommes pas confrontés au problème du déséquilibre des performances de notre système de stockage. C'est l'un des grands avantages de cette approche et l'une des principales raisons pour lesquelles elle est si vivement recommandée. Toutes les performances résident dans un pool partagé et les composants qui ont besoin de ces performances y ont accès.

Dans bien des cas, que ce soit dans une tentative d'amélioration des performances ou de la conception en matière de fiabilité, ou par nécessité technique, je constate que les gens séparent leurs grappes de stockage et placent les hyperviseurs et les systèmes d'exploitation sur une grappe et les données sur une autre. Mais ce qui me sidère, c'est que les grappes dédiées à l'hyperviseur ou au système d'exploitation sont souvent d'une capacité ahurissante et d'une performance extrêmement élevée – faisant souvent appel à des disques à 15 000 tr/min, voire à des disques à semi-conducteurs, à grands frais. Presque toujours en RAID 1 (conformément aux standards courants de 1998.)

Ce qu'il faut comprendre ici, c'est que les systèmes d'exploitation eux-mêmes n'ont, à toutes fins utiles, aucune exigence en matière d'E/S de stockage. Il y en a une faible quantité, principalement pour la journalisation système, mais c'est à peu près tout ce qui est nécessaire. Les partitions de système d'exploitation sont presque entièrement statiques. Les composants requis sont chargés en mémoire, principalement au moment du démarrage, et ne sont plus consultés par la suite. Même dans les cas où la journalisation est nécessaire, ces journaux sont bien souvent envoyés vers un système de journalisation centralisé et non vers la zone de stockage du système, ce qui réduit, voire supprime, ce besoin également.

Avec les hyperviseurs, cet effet est encore plus marqué. Comme les hyperviseurs sont bien plus légers et moins robustes que les systèmes d'exploitation traditionnels, ils se comportent davantage comme des systèmes embarqués et, à bien des égards, en sont effectivement dans de nombreux cas. Les hyperviseurs se chargent en mémoire au moment du démarrage du système et leur support n'est presque plus jamais sollicité tant qu'un système fonctionne, hormis pour la journalisation à certaines occasions. Parce que les hyperviseurs sont de petite taille physique, même le temps total nécessaire pour lire intégralement un hyperviseur complet depuis le stockage est très faible, même sur un support très lent, car la taille totale est très réduite.

Pour ces raisons, la performance du stockage n'a que peu ou pas d'incidence pour les systèmes d'exploitation et, plus particulièrement, pour les hyperviseurs. La différence entre un stockage rapide et un stockage lent n'a réellement d'impact que sur le temps de démarrage du système, où la différence entre une seconde et trente secondes ne serait que rarement remarquée, voire pas du tout. Qui percevrait ne serait-ce que plusieurs secondes supplémentaires lors du démarrage d'un système et, dans la plupart des cas, les démarrages sont des événements rares, survenant tout au plus une fois par semaine lors d'un redémarrage système automatisé et de routine pendant une fenêtre de maintenance planifiée ou, très rarement, parfois une seule fois tous les plusieurs années, pour des systèmes qui ne sont mis hors ligne qu'en cas d'urgence. Même le système de stockage le plus lent que l'on puisse concevoir est bien plus rapide que nécessaire pour ce rôle.

Même un stockage lent est généralement plusieurs fois plus rapide que ce qui est nécessaire pour les activités de journalisation système. Dans ces rares cas où la journalisation est très intense, nous disposons de nombreux choix pour aborder ce problème. La solution la plus évidente et la plus courante consiste ici à envoyer les journaux vers une grappe de disques autre que celle utilisée par le système d'exploitation ou l'hyperviseur. C'est une solution très simple et, en définitive, très pratique dans les cas où elle se justifie. L'autre solution courante et fort utile consiste simplement à s'abstenir de conserver les journaux sur le périphérique local et à les envoyer vers un utilitaire de collecte de journaux distant tel que Splunk, Loggly ou ELK.

L'autre préoccupation majeure que la plupart des gens nourrissent à l'égard de leurs systèmes d'exploitation et de leurs hyperviseurs est la fiabilité. Il est courant de concentrer davantage d'efforts sur la protection de ces aspects relativement peu importants d'un système plutôt que sur les données, souvent irremplaçables. Or, les systèmes d'exploitation et les hyperviseurs se reconstruisent aisément à partir de zéro en cas de besoin, au moyen d'installations propres et d'une reconfiguration manuelle lorsque c'est nécessaire. Les détails susceptibles d'être perdus sont en général relativement triviaux à recréer.

Cela ne signifie pas que ces systèmes de fichiers ne devraient pas être sauvegardés ; bien sûr qu'ils le devraient (dans la plupart des cas.) Mais, au cas où les sauvegardes échoueraient elles aussi, il est rare que la perte d'une partition ou d'un système de fichiers d'OS soit véritablement synonyme de tragédie, mais seulement d'un désagrément. Il existe des moyens de récupérer dans la quasi-totalité des cas sans accès aux données d'origine, pour autant que le système de fichiers de “données” soit distinct. Et, en raison de la nature des systèmes d'exploitation et des hyperviseurs, les changements sont rares, de sorte que les sauvegardes peuvent en général être moins fréquentes, possiblement déclenchées manuellement uniquement lorsque des mises à jour sont appliquées !

Avec de nombreux systèmes modernes dans les univers du DevOps et de l'informatique en nuage, il est devenu très courant de considérer les systèmes de fichiers des systèmes d'exploitation et des hyperviseurs comme entièrement jetables, dès lors qu'ils sont définis à distance via une image système ou par un système de gestion de configuration. Dans ces cas, qui deviennent de plus en plus fréquents, il n'est nul besoin de protection des données ni de sauvegardes, l'ensemble du système étant conçu pour être recréé, presque instantanément, sans aucune interaction particulière. Le système est entièrement auto-réplicant. Cela banalise davantage encore le besoin de protection du système de fichiers système.

Pris ensemble, l'absence de besoin en matière de performance ainsi que l'absence de besoin en matière de protection et de fiabilité, gérées principalement par une simple recréation, nous donnent un système de fichiers système aux besoins très différents de ce que nous présumons couramment. Cela ne signifie pas que nous devrions faire preuve de témérité avec notre stockage ; nous voulons toujours éviter une défaillance du stockage tant qu'un système fonctionne, et reconstruire inutilement constitue une perte de temps et de ressources, même si cela ne se révèle pas désastreux. Trouver un équilibre prudent est donc important.

C'est, bien entendu, pour ces raisons que l'inclusion du système d'exploitation ou de l'hyperviseur sur la même grappe de stockage que les données est désormais une pratique courante – parce qu'il n'y a que peu ou pas de besoin d'accès au stockage pour les fichiers système au moment même où il y a accès aux fichiers de données ; nous obtenons donc une grande synergie en bénéficiant de temps de démarrage rapides pour l'OS et d'aucun impact négatif sur les temps d'accès aux données une fois le système en ligne. C'est le principal moyen par lequel les concepteurs de systèmes répondent aujourd'hui au besoin d'une utilisation efficace du stockage.

Lorsque le système d'exploitation ou l'hyperviseur doit être séparé des grappes hébergeant les données, ce qui peut tout de même se produire pour une myriade de raisons, nous cherchons en général à obtenir une fiabilité raisonnable à faible coût. Avec un stockage traditionnel (disques locaux), cela signifie utiliser de petits disques mécaniques lents et peu coûteux pour le stockage du système d'exploitation, généralement dans une simple configuration RAID 1. Un exemple concret est l'utilisation de disques SATA “écologiques” à 5400 tr/min dans les plus petites tailles possibles. Ceux-ci consomment peu d'énergie et sont très peu onéreux à l'acquisition. Les SSD et les disques SAS haute vitesse seraient évités, car ils coûtent une prime pour une protection sans pertinence et une performance entièrement gaspillée.

Dans un stockage moins traditionnel, il est courant de recourir à un SAN à haute densité et à faible coût, consolidant le stockage de faible priorité de nombreux systèmes sur des grappes partagées et lentes qui ne sont pas répliquées. Cela n'est efficace que dans les environnements de plus grande taille, capables de justifier la conception architecturale supplémentaire et d'atteindre une densité suffisante dans le processus de consolidation du stockage pour générer les économies de coûts nécessaires ; mais, dans les environnements de plus grande taille, cela est relativement aisé. Les périphériques de démarrage SAN peuvent tirer parti de grappes à très faible coût réparties sur de nombreux serveurs en vue de réaliser des économies. Dans l'univers virtuel, cela pourrait se traduire par une banque de données à faible performance utilisée pour les disques virtuels de l'OS et un autre pool, à haute performance, pour les disques virtuels de données. Cela aurait le même effet que la stratégie de SAN de démarrage, mais dans un cadre plus moderne, et pourrait aisément s'appuyer sur l'architecture SAN sous le capot pour y parvenir.

Enfin, et de la manière la plus spectaculaire, c'est une règle empirique générale, avec les hyperviseurs, de les installer sur des cartes SD ou des clés USB plutôt que sur un stockage traditionnel, leurs besoins en performance et en fiabilité étant bien moindres encore que ceux des systèmes d'exploitation traditionnels. Normalement, si un disque de cette nature venait à défaillir tandis qu'un système fonctionne, ce dernier continuerait en réalité de fonctionner sans aucun problème, le disque n'étant jamais sollicité une fois le système initialement démarré. Ce n'est que lors d'un redémarrage qu'un problème serait constaté et, à ce moment-là, un périphérique de démarrage de secours pourrait être utilisé, tel qu'une carte SD ou une clé USB secondaire. C'est la recommandation officielle pour VMware vSphere, c'est fréquemment recommandé par les représentants de Microsoft pour HyperV et c'est officiellement pris en charge par les fournisseurs OEM de HyperV ; c'est par ailleurs souvent recommandé, mais de façon moins largement prise en charge, pour les systèmes Xen, XenServer et KVM. Utiliser des cartes SD ou des clés USB pour le stockage de l'hyperviseur transforme effectivement un serveur de virtualisation en système embarqué. Si cela peut paraître contre nature aux administrateurs système habitués à concevoir les disques traditionnels comme une nécessité pour les serveurs, il est important de se rappeler que des systèmes d'entreprise hautement critiques tels que les routeurs et les commutateurs durent des décennies et recourent à cette stratégie exacte, pour les raisons exactement identiques.

Une stratégie courante pour les hyperviseurs dans ce mode embarqué avec cartes SD ou clés USB consiste à disposer de deux de ces périphériques, lesquels peuvent en réalité être une carte SD et une clé USB, chacun comportant une copie de l'hyperviseur. Si l'un des périphériques tombe en panne, le démarrage sur le second périphérique est presque aussi efficace qu'un système RAID 1 traditionnel. Mais, à la différence de la plupart des configurations RAID 1 traditionnelles, nous disposons aussi d'un moyen relativement simple de tester les mises à jour système en ne mettant à jour qu'un seul périphérique de démarrage à la fois et en éprouvant le processus avant de mettre à jour le second périphérique de démarrage, ce qui nous laisse un repli fiable et bien testé au cas où une mise à jour de version tournerait mal. Ce procédé était en réalité courant sur les grands systèmes UNIX RISC, où les périphériques de démarrage étaient souvent des ensembles RAID 1 logiciels locaux prenant en charge une pratique similaire, particulièrement répandue dans les milieux AIX et Solaris.

Il convient également de noter que, si cette approche constitue la bonne pratique pour la plupart des scénarios d'hyperviseur, il n'existe en réalité aucune raison pour qu'elle ne puisse être appliquée aux systèmes de fichiers de systèmes d'exploitation complets également, si ce n'est qu'elle représente souvent davantage de travail. Certains OS, en particulier Linux et BSD, sont très aptes à être installés de manière embarquée et peuvent aisément être adaptés à une installation sur carte SD ou clé USB, moyennant un peu de planification. Cette approche n'est pas du tout courante, mais il n'existe aucune raison technique expliquant pourquoi, dans les circonstances appropriées, elle ne constituerait pas une excellente approche, hormis le fait qu'un OS ne devrait presque jamais être installé sur du matériel physique plutôt que par-dessus un hyperviseur. Dans ces cas où des installations physiques sont nécessaires, cette approche est alors extrêmement valable.

Lors de la conception et de la planification des systèmes de stockage, n'oubliez pas de prêter attention à ce à quoi ressembleront réellement les schémas de lecture et d'écriture lorsqu'un système fonctionnera. Et souvenez-vous que le stockage a évolué de manière assez spectaculaire depuis l'élaboration de nombre des lignes directrices traditionnelles et que l'ensemble du savoir ayant servi à les élaborer ne s'applique plus aujourd'hui, ou ne s'applique pas de manière égale. Réfléchissez non seulement aux sous-systèmes de stockage qui tenteront de mettre à profit la performance du stockage, mais aussi à la manière dont ils interagiront les uns avec les autres (par exemple, deux systèmes ne demandent-ils jamais un accès au stockage en même temps, ou entreront-ils régulièrement en conflit) et à l'importance ou non de leur performance d'accès. Les fonctions générales du système d'exploitation peuvent être extrêmement lentes sur un serveur de base de données sans impact négatif ; tout ce qui compte, c'est la vitesse à laquelle une base de données peut être consultée. Même l'accès aux binaires applicatifs est souvent sans pertinence puisqu'eux aussi, une fois chargés en mémoire, y demeurent, et que seule la vitesse de la mémoire influe sur la performance continue.

Rien de tout cela ne vise à suggérer que séparer les sous-systèmes de stockage de l'OS et des données soit conseillé ; bien souvent, ce ne l'est pas. J'ai écrit par le passé combien la consolidation de ces sous-systèmes constitue fort fréquemment la meilleure marche à suivre, et cela demeure vrai aujourd'hui. Mais il existe également de nombreux cas raisonnables où il est judicieux de séparer certains besoins de stockage les uns des autres, souvent lorsqu'on a affaire à des systèmes de grande ampleur où nous pouvons réduire les coûts en dédiant un stockage onéreux à certains besoins et un stockage peu coûteux à d'autres ; et c'est dans ces cas que je veux démontrer que les systèmes d'exploitation et les hyperviseurs devraient être considérés comme la priorité la plus faible, tant en matière de performance que de fiabilité, sauf dans les cas les plus extrêmes.