Les systèmes HP NonStop (précédemment connus sous le nom de «Tandem») sont connus pour leur haute disponibilité, leur fiabilité et leur prix élevé.Comment le HP (Tandem) Non stop se compare-t-il aux clusters Linux?
Comment les clusters basés sur Linux ou Unix se comparent-ils à ces aspects et à d'autres?
Sur une machine tolérante aux pannes, la tolérance aux pannes est gérée directement dans le matériel et transparente pour l'application. La programmation d'un cluster nécessite que vous manipuliez explicitement la tolérance aux pannes dans l'application.
En pratique, une architecture d'application en cluster est beaucoup plus complexe à générer et plus sujette aux erreurs qu'une application conçue pour une plate-forme tolérante aux pannes telle que NonStop. Cela signifie qu'il existe une plus grande marge de non-fiabilité entraînée par les bogues d'application, comme le London Stock Exchange found out the hard way. Ils avaient un système basé sur Tandem titulaire, qui était une architecture assez commune pour les applications de négociation boursière. Leur nouveau PDG avait la brillante idée que Microsoft était la voie à suivre et avait un conseil de big-5 pour construire un système .Net basé sur un cluster de 120 serveurs.
Le problème avec les applications en cluster est que les pannes peuvent être corrélées. Si un bogue d'application ou de configuration existe dans le système, il sera généralement répliqué sur tous les nœuds. Cela signifie que vous pouvez obtenir une seule situation ou un seul événement qui peut supprimer le cluster entier. La complexité supplémentaire des applications en cluster les rend plus sujettes aux erreurs de développement et de déploiement, ce qui augmente les chances que cela se produise. Un système en cluster basé sur (par exemple) Linux et J2EE est vulnérable aux mêmes types de modes de défaillance.
À mon humble avis ceci est un avantage majeur des architectures mainframe plus anciennes. Plusieurs fournisseurs (IBM, HP, DEC et probablement plusieurs autres auxquels je ne peux penser) ont fait des systèmes tolérants aux pannes. Le modèle de programmation sous-jacent pour ce type de système est quelque peu plus simple qu'un serveur d'applications n-tier en cluster. Cela signifie qu'il y a relativement peu de choses à faire et que pour un effort donné, vous pouvez obtenir un système plus fiable. Un nombre surprenant d'architectures anciennes sont encore bien vivantes et vivent assez confortablement dans leurs niches de marché. IBM vend encore beaucoup de machines de séries Z et I; Unisys fabrique toujours les séries A et 2200; VMS et NonStop sont toujours actifs dans HP. Les ventes de ces systèmes ne sont pas entièrement destinées aux clients existants - par exemple, un système de souscription commerciale (GENIUS) fonctionne sur les ISeries et reste un leader du marché dans ce créneau avec de nouveaux déploiements au moment où j'écris ces lignes. L'application a survécu à deux tentatives de réécriture (1 en Java et 1 en .Net) que je connais et la plate-forme 'Old School' ne semble pas vraiment gêner son style.
Je n'irais pas court-circuiter les vendeurs écran grattoir pour l'instant ...
gris & Reuter Transaction Processing: Concepts and Techniques est un peu sec et académique, mais il a un bon traitement de l'architecture des systèmes à tolérance de pannes. L'un des auteurs était un acteur clé dans la conception des systèmes de Tandem.
Était-ce le même projet de la Bourse de Londres dont Microsoft se vantait il y a environ un an dans ses publicités? –
Oui, le même. À l'époque (mi-2005), j'ai postulé pour un poste d'architecte DW chez LSE et m'a fait décrire ce projet. Je me souviens avoir pensé 'Qui le%! * &% L'a signé?' – ConcernedOfTunbridgeWells