Partager via

Conception d’architecture mainframe et midrange Azure

  • Article

Les équipements matériels mainframe et midrange constituent une famille de systèmes proposés par divers fournisseurs connus pour poursuivre depuis toujours des objectifs communs de haute performance, de débit élevé, voire de haute disponibilité. Ces systèmes sont souvent modulaires (pour une montée en puissance) et monolithiques, ce qui signifie qu’il s’agit de grandes structures dotées de multiples unités de traitement, ainsi que d’une mémoire et d’un stockage partagés.

Côté application, les programmes adoptent souvent l’une des deux approches suivantes : transactionnelle ou par lot. Dans les deux cas, plusieurs langages de programmation ont été utilisés, dont COBOL, PL/I, Natural, Fortran, REXX, etc. En dépit de l’âge et de la complexité de ces systèmes, il existe de nombreuses voies de migration vers Azure.

Côté données, celles-ci sont généralement stockées dans des fichiers et des bases de données. Les bases de données mainframe et midrange se présentent généralement sous différentes structures,, relationnelles, hiérarchiques, réseau ou autres. Il existe différents types de systèmes d’organisation des fichiers. Certains d’entre eux peuvent être indexés et faire office de magasins de clés/valeurs. En outre, l’encodage des données dans les systèmes mainframe peut différer de l’encodage habituellement géré dans d’autres systèmes. Par conséquent, les migrations de données nécessitent une planification initiale. Il existe de nombreuses options de migration vers la plateforme de données Azure.

Présentation de mainframe et midrange

Migration de systèmes hérités vers Azure

Dans de nombreux cas, les charges de travail mainframe et midrange, ainsi que d’autres charges de travail basées sur un serveur, peuvent être répliquées dans Azure avec peu voire pas de perte de fonctionnalités. Parfois, les utilisateurs ne décèlent aucun changement dans leurs systèmes sous-jacents. Dans d’autres cas, il existe des options pour la refactorisation et la réingénierie de la solution héritée dans une architecture alignée sur le cloud. Cela s’opère en conservant les mêmes fonctionnalités ou des fonctionnalités similaires. Les architectures décrites dans ce contenu (ainsi que les livres blancs et autres ressources cités plus bas dans cet article) aident à vous guider tout au long de ce processus.

Concepts relatifs aux systèmes mainframe et midrange

Dans nos architectures mainframe, nous utilisons les termes suivants.

Ordinateurs mainframe

Les ordinateurs mainframe ont été conçus à la fin des années 1950 en tant que serveurs dotés d’une capacité de montée en puissance, destinés à exécuter des transactions en ligne et du traitement par lots. C’est pourquoi les ordinateurs mainframe disposent de logiciels pour les formulaires de transactions en ligne (parfois appelées écrans verts) et de systèmes d’entrée/sortie haute performance pour le traitement de lots. Les ordinateurs mainframe ont la réputation d’être extrêmement fiables et disponibles, en plus de leur capacité à exécuter des transactions en ligne et des traitements par lots.

Stockage mainframe

La démystification des ordinateurs mainframe passe en partie par le décryptage de divers termes désignant des concepts qui se chevauchent. Par exemple, le stockage central, la mémoire réelle, le stockage réel et le stockage principal renvoient tous à un dispositif de stockage relié directement au processeur mainframe. Le matériel mainframe se compose de processeurs et de bien d’autres dispositifs, notamment des dispositifs de stockage à accès direct (DASD), des lecteurs de bande magnétique et plusieurs types de consoles utilisateur. Les bandes et les dispositifs DASD sont utilisés par les fonctions système et les programmes utilisateur.

Types de stockage physique :

  • Le stockage central se trouve directement sur le processeur mainframe. Il est également appelé stockage du processeur ou stockage réel.
  • Le stockage auxiliaire est séparé du mainframe. Il inclut le stockage sur des dispositifs de stockage à accès direct (DASD), également connu sous le nom de stockage de pagination.

MIPS

La mesure de millions d’instructions par seconde (MIPS) est une valeur constante indiquant le nombre de cycles par seconde que peut exécuter un ordinateur donné. Ces MIPS sont utilisées pour mesurer la puissance de calcul globale d’un ordinateur mainframe. Les fournisseurs de ces machines facturent les clients sur la base de l’utilisation qu’ils en font, mesurée en MIPS. Les clients peuvent augmenter la capacité des ordinateurs mainframe pour répondre à des exigences spécifiques. IBM tient à jour un indice de capacité des processeurs, qui indique la capacité relative des différents ordinateurs mainframe.

Le tableau suivant présente les seuils MIPS types pour les petites, moyennes et grandes entreprises (SORG, MORG et LORG).

Taille du client Utilisation de MIPS typique
PORG Moins de 500 MIPS
MORG 500 à 5 000 MIPS
GORG Plus de 5 000 MIPS

Données mainframe

Les données mainframe sont stockées et organisées de façons variées, des bases de données relationnelles ou hiérarchiques aux systèmes de fichiers à haut débit. Parmi les systèmes de données courants figurent les systèmes z/OS Db2 pour les données relationnelles, et IMS DB pour les données hiérarchiques. Pour le stockage de fichiers à haut débit, vous pourriez voir le système VSAM (méthode de stockage informatique de données d’IBM). Le tableau suivant recense certains des systèmes de données mainframe courants et leurs cibles de migration possibles dans Azure.

Source de données Plateforme cible dans Azure
z/OS Db2 et Db2 LUW Azure SQL DB, SQL Server sur machines virtuelles Azure, Db2 LUW sur machines virtuelles Azure, Oracle sur machines virtuelles Azure, Azure Database pour PostgreSQL
IMS DB Azure SQL DB, SQL Server sur machines virtuelles Azure, Db2 LUW sur machines virtuelles Azure, Oracle sur machines virtuelles Azure, Azure Cosmos DB
VSAM (Virtual Storage Access Method), ISAM (Indexed Sequential Access Method) pour les fichiers plats Azure SQL DB, SQL Server sur machines virtuelles Azure, Db2 LUW sur machines virtuelles Azure, Oracle sur machines virtuelles Azure, Azure Cosmos DB
GDG (Groupes de dates de génération) Fichiers sur Azure utilisant des extensions dans les conventions d’affectation de noms pour fournir des fonctionnalités similaires aux GDG

Systèmes midrange, variantes Unix et autres systèmes hérités

« Systèmes midrange » et « ordinateurs midrange » sont des termes vaguement définis pour désigner des systèmes informatiques plus puissants qu’un ordinateur personnel à usage général, mais moins puissant qu’un ordinateur mainframe de taille réelle. Dans la plupart des cas, un ordinateur midrange est utilisé en tant que serveur réseau, quand le nombre de systèmes clients est petit à moyen. Les ordinateurs disposent généralement de plusieurs processeurs, d’une grande quantité de mémoire vive (RAM) et de disques durs de grande taille. En outre, ils comprennent généralement des composants matériels permettant une mise en réseau avancée, ainsi que des ports pour la connexion à des périphériques davantage orientées entreprise (tels que des périphériques de stockage de données à grande échelle).

Parmi les systèmes courant dans cette catégorie figurent l’AS/400 et les IBM séries i et p. Unisys propose également un panoplie de systèmes midrange.

Système d’exploitation Unix

Le système d’exploitation Unix fut l’un des premiers systèmes d’exploitation de classe entreprise. Unix est le système d’exploitation de base pour Ubuntu, Solaris et les systèmes d’exploitation qui suivent les normes POSIX. Unix a été développé dans les années 1970 par Ken Thompson, Denis Ritchie, et d’autres collaborateurs au sein d’AT&T. Il fut conçu à l’origine pour des programmeurs développant des logiciels, plutôt que pour des non-programmeurs. Il fut distribué à des organisations gouvernementales et à des établissements scolaires, qui conduisirent UNIX à décliner un nombre croissant de variantes et ramifications offrant différentes fonctions spécialisées. UNIX et ses variantes (par exemple, AIX, HP-UX et Tru64) s’exécutent généralement sur des systèmes hérités, tels les ordinateurs mainframe IBM, les systèmes AS/400, ainsi que des systèmes basés sur l’architecture SPARC de Sun et sur du matériel DEC.

Autres systèmes

Parmi les autres systèmes hérités figure la famille de systèmes de Digital Equipment Corporation (DEC), tels que les systèmes DEC VAX, DEC Alpha et DEC PDP. Les systèmes DEC exécutaient initialement le système d’exploitation VMS pour VAX, avant d’évoluer vers des variantes Unix, telles que Tru64. D’autres systèmes sont ceux basés sur l’architecture PA-RISC, tels les systèmes HP-3000 et HP-9000.

Données et stockage midrange

Les données midrange sont stockées et organisées de différentes façons, des bases de données relationnelles ou hiérarchiques aux systèmes de fichiers à haut débit. Parmi les systèmes de données courants figurent les systèmes Db2 for i pour les données relationnelles, et IMS DB pour les données hiérarchiques. Le tableau suivant recense certains des systèmes de données mainframe courants et les cibles de migration possibles dans Azure.

Source de données Plateforme cible dans Azure
Db2 for i Azure SQL DB, SQL Server sur machines virtuelles Azure, Azure Database pour PostgreSQL, Db2 LUW sur machines virtuelles Azure, Oracle sur machines virtuelles Azure
IMS DB Azure SQL DB, SQL Server sur machines virtuelles Azure, Db2 LUW sur machines virtuelles Azure, Oracle sur machines virtuelles Azure, Azure Cosmos DB

Endianness

Tenez compte des détails suivants sur endianness :

  • Les processeurs RISC et x86 diffèrent sur le plan de l’endianness, un terme utilisé pour décrire la façon dont un système stocke les octets dans la mémoire de l’ordinateur.
  • Les ordinateurs basés sur RISC sont qualifiés de « Big Endian » parce qu’ils stockent la valeur la plus significative (« Big ») en premier, autrement dit, dans l’adresse de stockage la plus basse.
  • La plupart des ordinateurs Linux sont basés sur le processeur x86. Ceux-ci sont qualifiés de systèmes « mode Little Endian » parce qu'ils stockent la valeur la moins significative (« Little ») en premier.

La figure suivante illustre la différence entre Big Endian et Little Endian.

Explication de l’endianness

Types d’architectures de haut niveau

Réhébergement

Souvent appelée migration lift-and-shift, cette option ne nécessite pas de modification du code. Vous pouvez l’utiliser pour migrer rapidement vos applications existantes vers Azure. Chaque application est migrée en l’état, afin de profiter des avantages du cloud sans les risques et les coûts associés aux modifications du code.

Architectures de réhébergement

Refactorisation

La refactorisation nécessite des modifications minimes des applications. Cela permet souvent à l’architecture de l’application de tirer profit d’Azure PaaS (Platform as a service) ainsi que d'autres offres cloud. Par exemple, vous pouvez migrer des composants informatiques d’applications existantes vers Azure App Service ou Azure Kubernetes Service (AKS). Vous pouvez aussi refactoriser des bases de données relationnelles et non relationnelles en diverses options telles qu’Azure SQL Managed Instance, Azure Database pour MySQL, Azure Database pour PostgreSQL ou Azure Cosmos DB.

Architectures de refactorisation

Réingénierie

La réingénierie pour la migration porte principalement sur la modification et l’extension des fonctionnalités et de la base de code de l’application, avec pour objectif d’optimiser l’architecture de l’application pour la scalabilité cloud. Par exemple, vous pouvez décomposer une application monolithique en un groupe de microservices qui fonctionnent ensemble et sont facilement mis à l’échelle. Vous pouvez aussi réarchitecturer vos bases de données relationnelles et non relationnelles afin d’obtenir une solution de base de données complètement managée, comme SQL Managed Instance, Azure Database pour MySQL, Azure Database pour PostgreSQL et Azure Cosmos DB.

Architectures de réingénierie

Matériel dédié

Un autre modèle de migration vers Azure (pour des systèmes hérités) est ce qu’on appelle un matériel dédié. Dans ce modèle, le matériel existant (par exemple, IBM Power Systems) fonctionne à l’intérieur du centre de données Azure, avec un service géré par Azure englobant le matériel, ce qui facilite la gestion et l’automatisation du cloud. En outre, ce matériel est disponible pour la connexion à d’autres services Azure IaaS et PaaS et l’utilisation avec ceux-ci.

Architectures matérielles dédiées

Déplacement et migration de données

Une partie essentielle des migrations et transitions de ressources vers Azure est la prise en compte des données. Celle-ci peut inclure non seulement le déplacement des données, mais aussi la réplication et la synchronisation de celles-ci.

Architectures de déplacement et de migration de données

Étapes suivantes

Les livres blancs, blogs, webinaires et autres ressources sont disponibles pour vous aider dans votre parcours à comprendre les voies de migration d’anciens systèmes vers Azure :

Livres blancs

Webinaires

Billets de blog :

Témoignages client

Différents secteurs opèrent une migration de leurs systèmes mainframe et midrange hérités d’une manière à la fois innovante et inspirante. Consultez les études de cas client et des témoignages suivants :