Évolutivité est la capacité du système à s’adapter à des exigences croissantes et à des volumes croissants de tâches à résoudre.

Fonctionnement d’une solution d’application dans différentes conditions

Le système 1C:Enterprise 8 a de bonnes capacités de mise à l'échelle. Il permet de travailler aussi bien en mode fichier qu'en utilisant la technologie client-serveur.

• Usage personnel, version fichier de l'œuvre
  Lorsque vous travaillez dans la version fichier, la plateforme peut fonctionner avec une infobase locale située sur le même ordinateur sur lequel travaille l'utilisateur. Cette option de travail peut être utilisée à la maison ou lorsque vous travaillez sur un ordinateur portable.
• Petit groupe de travail, version fichier du travail
  L'option fichier offre également la possibilité à plusieurs utilisateurs de travailler sur un réseau local avec une seule base d'informations. Cette méthode de travail peut être utilisée en petits groupes de travail et est facile à installer et à utiliser.
• Grande entreprise, version client-serveur du travail
  Pour les grands groupes de travail et à l'échelle de l'entreprise, une version client-serveur du travail peut être utilisée, basée sur une architecture à trois niveaux utilisant le serveur 1C:Enterprise 8 et un système de gestion de base de données distinct. Il fournit un stockage de données fiable et un traitement efficace lorsqu'un grand nombre d'utilisateurs travaillent simultanément.
• Holding, base d'informations distribuée
  Les grandes sociétés holding peuvent utiliser le travail dans une base d'informations distribuée, en combinaison avec l'utilisation d'options de travail de fichiers et de client-serveur. Une base d'informations distribuée permet de fédérer les divisions d'une société holding éloignées les unes des autres, et chacune de ces divisions peut utiliser, à son tour, des options de fichiers ou de client-serveur. Le mécanisme de la base d'informations distribuée garantira l'identité des configurations utilisées dans chacune des divisions du fonds et échangera des données entre les bases d'informations individuelles incluses dans le système distribué.

Il est important de noter que les mêmes solutions applicatives (configurations) peuvent être utilisées dans les modes de fonctionnement fichier et client-serveur. Lors du passage de la version fichier à la technologie client-serveur, il n'est pas nécessaire d'apporter des modifications à la solution applicative. Par conséquent, le choix de l'option de travail dépend entièrement des besoins du client et de ses capacités financières. Au stade initial, vous pouvez travailler dans la version fichier, puis, à mesure que le nombre d'utilisateurs et le volume de la base de données augmentent, vous pouvez facilement passer à la version client-serveur du travail à partir de votre base d'informations.

Travail multi-utilisateurs

L'un des principaux indicateurs de l'évolutivité du système est la capacité à travailler efficacement avec une augmentation du nombre de tâches à résoudre, du volume de données traitées et du nombre d'utilisateurs travaillant de manière intensive :

La version client-serveur offre la possibilité à un grand nombre d'utilisateurs de travailler en parallèle. Les tests montrent qu'à mesure que le nombre d'utilisateurs augmente, la vitesse de saisie des documents diminue très lentement. Cela signifie qu'à mesure que le nombre d'utilisateurs intensifs augmente, la vitesse de réponse du système automatisé reste à un niveau acceptable.

Dans le modèle de données pris en charge par le système 1C:Enterprise 8, il n'existe pas de tables de base de données conduisant clairement à un accès simultané de plusieurs utilisateurs. L'accès simultané se produit uniquement lors de l'accès à des données logiquement liées et n'affecte pas les données qui ne sont pas liées les unes aux autres du point de vue du domaine.

Lors de l'exécution d'opérations de routine, les situations dans lesquelles l'installation d'un mode exclusif est nécessaire pour commencer les travaux au cours d'une certaine période de rapport sont exclues. Les opérations de routine peuvent être effectuées à des moments qui conviennent aux utilisateurs et à l'organisation. Le mode exclusif n'est pas installé au démarrage du système, mais au moment où il est nécessaire d'effectuer une opération qui nécessite son activation. Après avoir effectué de telles opérations, le mode exclusif peut être désactivé.

Mécanismes d'optimisation

La plate-forme technologique 1C:Enterprise 8 contient un certain nombre de mécanismes qui optimisent la vitesse des solutions applicatives.

Exécution sur le serveur

Dans la version client-serveur, l'utilisation du serveur 1C:Enterprise 8 permet de concentrer sur lui les opérations de traitement de données les plus poussées. Par exemple, lors de l'exécution de requêtes même très complexes, le programme exécuté pour l'utilisateur recevra uniquement la sélection dont il a besoin et tous les traitements intermédiaires seront effectués sur le serveur. En règle générale, il est beaucoup plus facile d’augmenter la capacité du serveur que de mettre à niveau l’ensemble du parc de machines client.

Mise en cache des données

Le système 1C:Enterprise 8 utilise un mécanisme de mise en cache des données lues à partir de la base de données lors de l'utilisation de la technologie objet. Lors de l'accès à un attribut d'objet, toutes les données de l'objet sont lues dans un cache situé dans la RAM. Les appels ultérieurs aux détails du même objet seront envoyés au cache, et non à la base de données, ce qui réduit considérablement le temps passé à récupérer les données nécessaires.

Fonctionnement du langage intégré sur le serveur

Lorsque vous travaillez dans la version client-serveur, tout le travail des objets d'application est effectué uniquement sur le serveur. La fonctionnalité des formulaires et de l'interface de commande est également implémentée sur le serveur.

Le serveur prépare les données du formulaire, organise les éléments et enregistre les données du formulaire après modifications. Le client affiche un formulaire déjà préparé sur le serveur, saisit les données et appelle le serveur pour enregistrer les données saisies et d'autres actions nécessaires.

De même, l'interface de commande est constituée sur le serveur et affichée sur le client. De plus, les rapports sont entièrement générés sur le serveur et affichés sur le client.

Versions 8.1 et 8.0 - comparaison des performances et de l'évolutivité

Pour évaluer l'évolution des performances et de l'évolutivité du système dans diverses conditions, un certain nombre de tests ont été effectués dans la version 8.1 :

• Évaluation des performances et de l'évolutivité du système lorsqu'un grand nombre d'utilisateurs travaillent simultanément
• Évaluation des performances et de l'évolutivité du système sous des charges de pointe
• Évaluation des performances pour certains types d’opérations

Les indicateurs obtenus pour 1C:Enterprise 8.1 ont été comparés à des indicateurs similaires

pour 1C : Entreprise 8.

Versions 7.7 et 8.0 - comparaison des performances et de l'évolutivité

Pour évaluer les performances et l'évolutivité de la version client-serveur de 1C:Enterprise 8, un certain nombre de tests ont été réalisés, permettant :

• comparer et montrer les avantages de 1C:Enterprise 8 dans les modes de fonctionnement standard ;
• évaluer l'évolutivité de 1C:Enterprise 8 avec une intensité de charge croissante et un volume croissant de données traitées ;
• évaluer l'évolutivité de 1C:Enterprise 8 lors de l'augmentation des ressources informatiques des équipements utilisés ;
• évaluer les performances et les performances de 1C:Enterprise 8 lorsqu'il fonctionne dans des conditions de charge de pointe ;
• évaluer l'efficacité de l'utilisation de plates-formes multiprocesseurs pour résoudre les problèmes de 1C:Enterprise 8.

Évaluation de l'évolutivité de la solution Manufacturing Enterprise Management

Des tests ont été effectués pour évaluer l'évolutivité de la solution applicative Manufacturing Enterprise Management (PEM) avec le fonctionnement simultané d'un grand nombre d'utilisateurs.

Lors de la réalisation du test, des approches généralement acceptées pour évaluer les performances des systèmes d'information d'entreprise ont été utilisées :

• À utiliser pour tester une solution d'application typique.
• Tester les opérations les plus critiques du point de vue du fonctionnement d’une organisation typique.
• Opérations de test sous paramètres fixes, typiques de la plupart des organisations
• Simulation logicielle de scénarios de travail typiques pour les utilisateurs du système, créant une charge qui dépasse largement la charge créée par les utilisateurs réels
• En utilisant le volume de transactions commerciales reflété dans le système par unité de temps et le temps moyen nécessaire pour terminer une opération comme principaux indicateurs.

Exemples de paramètres technologiques pour la mise en œuvre de la solution « Manufacturing Enterprise Management »

Cette section publie des informations détaillées sur les paramètres technologiques de la mise en œuvre de « 1C : Enterprise 8. Manufacturing Enterprise Management » dans des entreprises de différentes tailles et profils d'activité.

Le but de cette section est de familiariser les informaticiens avec les données sur les équipements réellement utilisés et avec des exemples de charge d'implémentations réelles de 1C:Enterprise 8.

Ces informations peuvent également être utiles aux utilisateurs de tous les programmes du système 1C:Enterprise 8.

Sélection d'équipement

Ce document fournit des informations sur la manière dont les caractéristiques de l'équipement affectent l'efficacité de l'utilisation du système dans différents modes et fournit des recommandations pour la sélection de l'équipement en fonction des tâches à résoudre.

1C:Performance Management Center - outil de suivi et d'analyse des performances

1C:Performance Management Center (1C:PMC) est un outil de surveillance et d'analyse des performances des systèmes d'information sur la plate-forme 1C:Enterprise 8. 1C:PMC est conçu pour évaluer les performances du système, collecter des informations techniques détaillées sur les problèmes de performances existants et les analyser. ces informations à des fins d'optimisation ultérieure.

1C:TestCenter - outil d'automatisation des tests de charge

1C:TestCenter est un outil permettant d'automatiser les tests de charge multi-utilisateurs des systèmes d'information sur la plateforme 1C:Enterprise 8. Avec son aide, vous pouvez simuler le fonctionnement d'une entreprise sans la participation d'utilisateurs réels, ce qui vous permet d'évaluer l'applicabilité. , la performance et l'évolutivité d'un système d'information en conditions réelles.

Implémentation des systèmes d'informations d'entreprise sur la plateforme
1C : Entreprise 8

L'expérience dans la mise en œuvre de solutions d'application sur la plate-forme 1C:Enterprise 8 montre que le système vous permet de résoudre des problèmes plus ou moins complexes - de l'automatisation d'un lieu de travail à la création de systèmes d'information à l'échelle de l'entreprise.

Dans le même temps, la mise en œuvre d’un grand système d’information impose des exigences accrues par rapport à une mise en œuvre de petite ou moyenne taille. Un système d'information à l'échelle de l'entreprise doit fournir des performances acceptables dans des conditions de travail simultané et intensif d'un grand nombre d'utilisateurs qui utilisent les mêmes ressources d'information et matérielles en mode compétitif.

Oleg Spiriaev

Récemment, des allégations ont été fréquentes selon lesquelles les serveurs milieu et haut de gamme seraient activement remplacés par des groupes de serveurs d'entrée de gamme, réunis dans des racks ou des clusters. Cependant, certains experts ne sont pas d’accord. Ainsi, selon Dataquest, la part des modèles évalués à 500 000 $ et plus (cela inclut les serveurs SMP de milieu de gamme et haut de gamme) dans les ventes totales de serveurs entre 2000 et 2002 est passée de 38 à 52 %.

D'autres données obtenues par IDC indiquent une croissance (au moins en termes de nombre de machines) dans le secteur des modèles de serveurs bas de gamme - à deux processeurs. IDC prédit également qu'en 2005, le système d'exploitation le plus courant pour les serveurs coûtant entre 50 000 et 3 millions de dollars sera Unix. En comparant ces données, il est clair que les serveurs Unix de milieu de gamme et haut de gamme resteront la plate-forme prédominante pour les centres de données, mais seront complétés par un nombre croissant de serveurs plus petits (généralement à double processeur).

Cette tendance est apparue à la suite de la séparation des différentes couches informatiques dans les centres de données (Fig. 1). Le niveau 1, ou niveau frontal, évolue progressivement vers un modèle évolutif de petits serveurs, tandis que le niveau 3 (le niveau base de données) est dominé par des serveurs évolutifs. La couche 2 (couche application) devient la zone où cohabitent les architectures verticales et horizontales.

Architectures verticales et horizontales

Examinons les principales différences entre les architectures verticales et horizontales. Les serveurs évolutifs sont de grands systèmes SMP (multitraitement symétrique ou mémoire partagée) dotés de plus de quatre unités centrales de traitement. Ils n'utilisent qu'une seule copie du système d'exploitation pour gérer tous les processeurs, la mémoire et les composants d'E/S. En règle générale, toutes ces ressources sont hébergées dans un seul rack ou armoire. Ces serveurs s'interconnectent via un panneau central ou un fond de panier à haut débit avec une faible latence et un accès cohérent au cache. Vous pouvez ajouter des ressources en installant des cartes mères supplémentaires à l'intérieur du coffret. Dans les systèmes à architecture tour (ou SMP), la mémoire est partagée, ce qui signifie que tous les processeurs et composants d'E/S ont accès à toute la mémoire. L'utilisateur « voit » la mémoire comme un seul grand objet.

Dans une mise à l'échelle horizontale alternative, les systèmes sont connectés via un réseau ou regroupés. Les interconnexions utilisent généralement des technologies réseau standard telles que Fast Ethernet, Gigabit Ethernet (GBE) et Scalable Coherent Interconnect (SCI), qui offrent un débit inférieur et une latence plus élevée que les systèmes verticaux. Dans ce cas, les ressources sont réparties entre les nœuds, contenant généralement de un à quatre processeurs ; Chaque nœud possède son propre processeur et sa propre mémoire et peut avoir son propre sous-système d'E/S ou le partager avec d'autres nœuds. Chaque nœud exécute une copie distincte du système d'exploitation. Les ressources sont étendues en ajoutant des nœuds, mais pas en ajoutant des ressources à un nœud. La mémoire dans les systèmes horizontaux est distribuée, c'est-à-dire que chaque nœud possède sa propre mémoire à laquelle ses processeurs et son sous-système d'E/S accèdent directement. L'accès à ces ressources depuis un autre nœud est beaucoup plus lent que depuis le nœud où elles se trouvent. De plus, avec une architecture horizontale, il n'y a pas d'accès cohérent entre les nœuds à la mémoire, et les applications utilisées consomment relativement peu de ressources, elles « tiennent » donc sur un seul nœud et n'ont pas besoin d'un accès cohérent. Si une application nécessite plusieurs nœuds, elle doit elle-même fournir un accès mémoire cohérent.

Si un système horizontal répond aux exigences de l'application, alors cette architecture est préférable car ses coûts d'acquisition sont moindres. Généralement, le coût d'acquisition par processeur pour les systèmes horizontaux est inférieur à celui des systèmes verticaux. La différence de prix est due au fait que les systèmes verticaux utilisent des fonctionnalités RAS (fiabilité, disponibilité, facilité d'entretien) plus puissantes, ainsi que des interconnexions hautes performances. Cependant, il existe un certain nombre de restrictions quant à l'utilisation de systèmes à architecture horizontale. Nous discuterons ci-dessous dans quelles conditions les systèmes horizontaux peuvent être utilisés et quand une mise à l'échelle verticale est nécessaire.

Outre un grand serveur SMP, l'architecture verticale comprend également des clusters de grands serveurs SMP utilisés pour une seule application à grande échelle.

Les serveurs modulaires ou lames récemment introduits sur le marché, généralement équipés d'un ou deux processeurs, sont un exemple de serveurs horizontaux. Ici, le cluster est constitué de petits nœuds, chacun disposant d'un serveur SMP d'entrée de gamme avec un nombre de processeurs centraux de 1 à 4.

Une autre façon d'évoluer consiste à utiliser de grands systèmes de calcul massivement parallèle (MPP), composés de nombreux petits processeurs installés dans une seule armoire, chacun avec sa propre copie du système d'exploitation ou une copie du micro-noyau du système d'exploitation. Actuellement, seuls quelques systèmes MPP sont produits, qui représentent le plus souvent des solutions spécialisées. Il s'agit par exemple des systèmes Terradata fabriqués par NCR, IBM RS/6000SP (SP-2) et HP Tandem non-stop.

Tableau 1. Caractéristiques des architectures verticales et horizontales

Paramètre	Systèmes verticaux	Systèmes horizontaux
Mémoire	Grand partagé	Petit dédié
Flux	De nombreux fils interdépendants	De nombreux fils de discussion indépendants
Interconnexions	Interne étroitement couplé	Externe faiblement couplé
RAS	Système unique RAS puissant	RAS puissant utilisant la réplication
Unités centrales de traitement	De nombreuses normes	De nombreuses normes
Système d'exploitation	Une copie du système d'exploitation pour de nombreux processeurs centraux	Plusieurs copies du système d'exploitation (une copie pour 1 à 4 processeurs)
Mise en page	Dans un placard	Placer un grand nombre de serveurs dans un rack
Densité		Densité de processeur élevée par unité de surface au sol
Équipement	Standard et spécialement conçu	Standard
Mise à l'échelle	Dans un seul châssis de serveur	À l'échelle multi-serveurs
Extension	En installant des composants supplémentaires sur le serveur	En ajoutant de nouveaux nœuds
Architecture	64 bits	32 et 64 bits

Tableau 1 permet une analyse comparative des architectures verticales et horizontales.

• Les systèmes verticaux partagent la mémoire et fournissent un accès cohérent au cache.
• Les systèmes verticaux sont idéaux pour les flux de tâches qui doivent communiquer entre eux.
• Les systèmes verticaux se caractérisent par de puissantes fonctions RAS, et dans les systèmes horizontaux, la disponibilité est mise en œuvre par réplication massive (plusieurs nœuds sont connectés à un cluster, donc la panne de l'un d'entre eux a peu d'impact sur le fonctionnement de l'ensemble du système).
• Dans les systèmes verticaux, une copie du système d'exploitation couvre toutes les ressources. Certains systèmes verticaux, tels que les serveurs midframe et haut de gamme de Sun Microsystems (Sun Fire 4800 à Sun Fire 15K), peuvent être divisés en serveurs verticaux plus petits.
• Les systèmes verticaux utilisent autant de composants standards que possible, mais certains composants clés (tels que les interconnexions) sont spécialement conçus.
• Les systèmes verticaux peuvent être étendus en installant des composants supplémentaires dans le cadre existant (processeurs plus puissants, mémoire supplémentaire, connexions E/S supplémentaires et plus performantes, etc.). Les systèmes horizontaux sont étendus en ajoutant un nœud ou en remplaçant les anciens nœuds par de nouveaux.
• Presque tous les systèmes verticaux sont en 64 bits, tandis que les systèmes horizontaux peuvent être en 32 bits ou en 64 bits.

Les systèmes verticaux conviennent mieux à certains types d’applications et les systèmes horizontaux à d’autres, mais dans de nombreux cas, le choix optimal de l’architecture dépend de l’ampleur du problème. Dans le tableau La figure 2 montre des exemples d'applications pour lesquelles une architecture verticale ou horizontale est optimale.

Tableau 2. Types d'applications pour les architectures verticales et horizontales

Les serveurs petits et modulaires conviennent parfaitement aux applications sans état, de petite taille et facilement répliquées. Et pour les applications qui utilisent des informations d'état et de gros volumes de données nécessitant un transfert intensif de données au sein du système, les serveurs verticaux constituent la solution idéale.

Sur le marché du calcul technique haute performance (HPTC), il existe de nombreuses applications dans lesquelles les threads dépendent les uns des autres et échangent des données entre eux. Il existe également des applications qui nécessitent de grandes quantités de mémoire partagée. Les grands serveurs SMP sont les mieux adaptés à ces deux types d'applications.

Cependant, il existe également des applications HPTC dans lesquelles les threads d'exécution sont indépendants et ne nécessitent pas de grandes quantités de mémoire partagée. Ces applications peuvent être partitionnées, ce qui rend les clusters de petits serveurs idéaux pour les exécuter. De même, certaines applications commerciales sont partitionnées et bénéficient de serveurs horizontaux, tandis que d'autres ne peuvent pas être partitionnées, les serveurs verticaux constituent donc la meilleure plate-forme pour elles.

Facteurs affectant les performances

Les processeurs sont certes un composant essentiel, mais ils ne déterminent qu’en partie les performances globales d’un système. Il est plus important de s’assurer que les processeurs fonctionnent à leur capacité maximale. Un processeur puissant chargé à seulement 50 % fonctionnera moins bien qu'un processeur plus lent chargé à 80 %.

De plus, à mesure que le nombre de processeurs dans un système parallèle augmente, ce sont les interconnexions du système plutôt que la puissance du processeur qui passent au premier plan. Ils sont responsables du déplacement des données du disque, de la mémoire et du réseau vers le processeur. Dans un cluster, l'interconnexion est une connexion réseau, telle que Fast Ethernet ou Gigabit Ethernet. Les interconnexions de cluster déplacent les données entre les nœuds, tandis que les interconnexions de systèmes déplacent les données au sein d'un seul système. Si l'interconnexion est trop lente, le processeur restera inactif en attendant les données.

Les interconnexions système sont également utilisées pour déplacer les adresses de données, ce qui est nécessaire pour prendre en charge la cohérence du cache. Si l'interconnexion du système est trop lente dans la transmission des adresses de données, le processeur sera à nouveau inactif en attendant les données car il a besoin de connaître son adresse pour y accéder. Les interconnexions rapides offrent un débit élevé et une faible latence (faible temps entre le moment où une demande de données est effectuée et le moment où les données commencent à être transmises).

La principale différence technique entre les systèmes horizontaux et verticaux réside dans le débit et la latence de leurs interconnexions. Pour les interconnexions de cluster, le débit peut aller de 125 Mo/s pour Fast Ethernet à 200 Mo/s pour SCI, et la latence peut aller de 100 000 ns pour GBE et jusqu'à 10 000 ns pour SCI. Grâce à l'interface InfiniBand, il est possible de mettre en œuvre des interconnexions plus rapides avec des vitesses de pointe allant d'environ 250 Mo/s pour la première version et jusqu'à 3 Go/s pour les suivantes.

Entrée et sortie

Des E/S rapides sont nécessaires pour que l'interconnexion puisse récupérer rapidement les données du disque et du réseau et les transférer vers les processeurs. Un goulot d'étranglement dans le sous-système d'E/S peut avoir un impact négatif sur les performances, même des interconnexions et des processeurs les plus rapides.

système opérateur

Même le meilleur matériel est inefficace si le système d’exploitation n’est pas suffisamment évolutif. Pour les systèmes horizontaux, l'évolutivité du système d'exploitation n'est pas si importante, car pas plus de quatre processeurs ne fonctionnent sur un seul nœud ou avec une copie distincte du système d'exploitation.

Disponibilité du système

D'une manière générale, la disponibilité du système dépend largement du type d'architecture. Dans les grands systèmes SMP, la fonctionnalité RAS est intégrée au système et complétée par un basculement pour deux à quatre nœuds. Dans les systèmes horizontaux, le RAS des nœuds individuels est pire, mais des améliorations de ces fonctions sont obtenues en répliquant les nœuds plusieurs fois.

Applications optimisées

Les applications doivent être optimisées pour l'architecture du système informatique. Il est plus simple d'écrire et d'optimiser des applications pour les systèmes SMP. Les principales applications commerciales sont optimisées spécifiquement pour les systèmes SMP et ont même été développées sur ceux-ci. C'est pourquoi les SMP ont dominé le marché des systèmes milieu et haut de gamme au cours des dix dernières années.

Taille de la demande

Comme indiqué, les grands systèmes SMP utilisent des interconnexions à haut débit pour fournir des performances système suffisantes. Les systèmes horizontaux peuvent rencontrer des problèmes de performances en raison d'un faible débit et d'une latence d'interconnexion élevée dans les cas où les données doivent être transférées fréquemment entre les nœuds. Toutefois, certaines applications ne nécessitent pas de vitesses d'interconnexion élevées pour atteindre des performances élevées : il s'agit généralement de petites applications et d'applications faciles à répliquer (par exemple, les serveurs Web, les proxys, les pare-feu et les petits serveurs d'applications). Dans de tels systèmes horizontaux, chaque nœud effectue une petite tâche indépendamment du travail de tous les autres.

Par exemple, dans une architecture horizontale (ou à mémoire distribuée), quatre nœuds de processeur (chacun avec une RAM séparée et un sous-système d'E/S dédié ou partagé) peuvent utiliser une interconnexion réseau telle que Gigabit Ethernet. Cet environnement informatique exécute trois types de charges de travail. La plus petite charge tient sur un nœud, mais à mesure qu'elle augmente, plusieurs nœuds sont nécessaires pour la compléter. Selon les experts, lors de l'exécution d'une tâche sur plusieurs nœuds, les performances se détériorent considérablement en raison de la lenteur des interconnexions entre les nœuds. Les petites charges de travail qui n'ont pas besoin de communiquer entre elles fonctionnent bien avec une architecture horizontale, mais y exécuter des charges de travail à grande échelle présente des défis.

Une grande configuration de système SMP peut inclure, par exemple, jusqu'à 100 processeurs, 576 Go de mémoire partagée et des interconnexions à haut débit. Un tel système peut gérer tous les types de charges de travail car il n'y a pas de communication entre les nœuds et une communication efficace entre les processus. Toutes les unités centrales de traitement peuvent accéder simultanément à tous les disques, à toutes les mémoires et aux connexions réseau - c'est une caractéristique clé des systèmes SMP (ou systèmes verticaux).

La question se pose souvent de l'opportunité de placer de petites charges sur de gros SMP. Bien que cela soit techniquement possible, d’un point de vue économique, cette approche n’est pas justifiée. Pour les grands SMP, le coût d'acquisition par processeur est plus élevé que pour les petits systèmes. Par conséquent, si une application peut s’exécuter sur un petit nœud (ou plusieurs petits nœuds) sans problèmes de gestion majeurs, la mise à l’échelle est un meilleur choix pour le déploiement. Mais si l'application est trop volumineuse pour s'exécuter sur un petit nœud (ou plusieurs nœuds), alors un grand serveur SMP sera la meilleure option en termes de performances et d'administration système.

Performances au niveau de la base de données

La principale question ici est de comparer les performances de serveurs SMP uniques de moyenne et grande taille avec un cluster de petits serveurs (pas plus de quatre processeurs).

Lorsqu’elles parlent d’évolutivité, les entreprises manufacturières utilisent un certain nombre de termes techniques. Ainsi, la croissance des performances (Speedup) pour SMP est définie comme le rapport des vitesses d'exécution des applications sur plusieurs processeurs et sur un. L'accélération linéaire signifie, par exemple, que sur 40 processeurs, une application s'exécute 40 fois (40x) plus rapidement que sur un seul. L'augmentation des performances ne dépend pas du nombre de processeurs, c'est à dire que pour une configuration de 24 processeurs elle sera la même que pour 48 processeurs. L'augmentation des performances du cluster (Cluster speedup) ne diffère que par le fait que lors de son calcul, le nombre de nœuds est pris en compte et non le nombre de processeurs. Tout comme la croissance des performances SMP, la croissance des performances du cluster reste constante sur différents nombres de nœuds.

L'efficacité de mise à l'échelle caractérise la capacité des applications, en particulier celles en cluster, à évoluer sur un grand nombre de nœuds. On pense généralement que l’efficacité de la mise à l’échelle dépend du nombre de nœuds participant à la mesure. L'efficacité de mise à l'échelle SMP est l'augmentation des performances divisée par le nombre de processeurs, et l'efficacité du cluster est l'augmentation des performances du cluster divisée par le nombre de nœuds qu'il contient. Vous devez comprendre la signification de ces paramètres afin de ne pas vous tromper, car une efficacité de mise à l'échelle de 90 % sur deux nœuds n'est pas la même chose qu'une efficacité de mise à l'échelle de 90 % sur quatre nœuds.

Sur la fig. La figure 2 montre trois graphiques : évolutivité linéaire idéale, évolutivité d'un serveur SMP à 24 processeurs à 95 % et évolutivité d'un cluster de deux serveurs à 4 processeurs à 90 %. On peut constater qu'il existe certaines limites à l'évolutivité des bases de données en clusters (avec mise à l'échelle horizontale). Le chaînage de nombreux petits serveurs n’offre pas l’évolutivité nécessaire aux applications de moyenne à grande taille. La raison en est les limitations de bande passante des interconnexions intra-clusters, la charge supplémentaire sur les logiciels de base de données associée à la gestion des clusters et la difficulté d'écrire des applications pour les environnements de clusters à mémoire distribuée.

Les résultats de référence publiés montrent, par exemple, qu'Oracle9i RAC (Real Application Cluster) présente un gain de performances de 1,8 et une efficacité de mise à l'échelle de 90 %. Cette efficacité d'évolutivité peut sembler assez élevée, mais en réalité, une évolutivité de 90 % pour quatre nœuds est inefficace par rapport aux résultats des grands serveurs SMP.

Performances au niveau des applications

La couche application dans un centre de données à trois niveaux est très différente de la couche base de données. En règle générale, les applications à ce niveau sont sans état - en d'autres termes, aucune donnée n'est stockée sur le serveur lui-même, ou seule une petite partie d'entre elles est stockée. Cette couche contient des règles métier pour les services d'application. Les transactions arrivent au niveau de l'application et sont traitées par celle-ci. Lorsque les données doivent être écrites ou lues, les transactions sont transmises à la couche de base de données. Les serveurs d'applications ont tendance à consolider les connexions aux bases de données, car un grand nombre de connexions a un impact négatif sur les performances.

Dans la plupart des cas, le niveau serveur d'applications nécessite beaucoup plus de processeurs que le niveau base de données par service d'application individuel. Par exemple, dans le cas de SAP R/3, ce ratio est d'environ 10 processeurs pour chaque processeur de base de données, c'est-à-dire que si SAP R/3 nécessite 20 processeurs pour la couche base de données, alors il devrait y avoir environ 200 processeurs pour la couche application. La question est de savoir ce qui est le plus rentable à déployer : 100 serveurs à deux processeurs ou dix serveurs à 20 processeurs. De même, chez Oracle, le ratio processeurs d'application/processeurs de base de données est d'environ 5 pour 1.

On pense qu'il n'est pas nécessaire que les serveurs d'applications soient répartis sur plusieurs nœuds. Plusieurs copies du logiciel d'application peuvent être distribuées sur différents serveurs physiques de différentes capacités ou sur des domaines dynamiques de grands serveurs.

Le nombre de processeurs requis pour la couche application sera approximativement le même quelle que soit l'architecture informatique. Le coût d'achat du matériel et des logiciels pour une architecture horizontale sera inférieur, puisque le coût par processeur est dans ce cas inférieur. Dans la plupart des cas, les systèmes horizontaux peuvent fournir les performances requises pour respecter l'accord de niveau de service. Les coûts associés à l'achat de licences logicielles sont à peu près les mêmes pour les deux architectures.

Dans le même temps, les coûts de gestion et de maintenance des infrastructures pour une architecture horizontale peuvent être plus élevés. Lorsqu'ils sont déployés sur des systèmes horizontaux, plusieurs copies du système d'exploitation et du logiciel du serveur d'applications sont utilisées. Les coûts de maintenance de l'infrastructure augmentent généralement proportionnellement au nombre de copies du système d'exploitation et des applications. De plus, avec une architecture horizontale, la sauvegarde et la reprise après sinistre deviennent décentralisées et l'infrastructure réseau est plus difficile à gérer.

Le coût de l'administration du système est difficile à mesurer. Généralement, les modèles comparant les déploiements de serveurs d'applications horizontaux et verticaux montrent que la gestion d'un nombre réduit de serveurs plus puissants (serveurs verticaux) est moins coûteuse que la gestion d'un grand nombre de serveurs plus petits. En général, lors du choix du type d'architecture pour déployer une couche d'application, les responsables informatiques doivent soigneusement considérer le coût d'acquisition du matériel.

Impact de l'architecture sur la disponibilité

La disponibilité est essentielle pour les centres de données modernes : les services d'application doivent être disponibles 24 heures sur 24, 7 jours sur 7 et 365 jours par an (24 heures sur 24, 7 jours sur 7, 365 jours par an). En fonction des besoins d'un centre de données particulier, différents schémas de haute disponibilité sont utilisés. Pour sélectionner une solution spécifique, il est nécessaire de déterminer le temps d'arrêt acceptable (planifié et non planifié). Sur la fig. La figure 3 montre comment le pourcentage de disponibilité affecte la durée du temps d'arrêt.

À mesure que les exigences de disponibilité augmentent, le coût de la solution augmente également. Les gestionnaires de centres de données doivent déterminer quelle combinaison de coût, de complexité et de disponibilité répond le mieux aux exigences de niveau de service. Les centres de données qui nécessitent une disponibilité d'environ 99,95 % peuvent déployer un seul serveur SMP doté de fonctionnalités RAS telles qu'une redondance matérielle complète et une maintenance en ligne.

Cependant, pour atteindre une disponibilité supérieure à 99,95%, un cluster sera nécessaire. Le logiciel Sun Cluster avec basculement HA (haute disponibilité) offre une disponibilité de 99,975 %. Le basculement HA utilise un serveur principal et un serveur de secours automatique ; Si le serveur principal tombe en panne, le serveur de sauvegarde prend en charge sa charge. Le temps nécessaire au redémarrage d'un service varie selon l'application et peut prendre plusieurs minutes, en particulier pour les applications de base de données qui nécessitent des restaurations volumineuses de données pour restaurer les transactions.

Si un temps d'arrêt de quelques minutes est inacceptable pour un centre de données, un système actif-actif peut être une solution, où l'application est déployée sur deux nœuds ou plus de sorte que si l'un d'entre eux tombe en panne, les autres continuent d'exécuter l'application. En conséquence, la panne sera très courte (certains clients signalent qu'elle dure moins d'une minute), parfois l'utilisateur peut même ne pas remarquer la panne du nœud.

Les serveurs verticaux offrent une haute disponibilité en intégrant de nombreuses fonctionnalités RAS dans un seul serveur afin de minimiser les temps d'arrêt planifiés et imprévus. Dans les serveurs horizontaux, les fonctions fournissant un niveau élevé de RAS ne sont pas mises en œuvre au niveau d'un serveur individuel, mais par duplication et placement de plusieurs serveurs. En raison des différentes implémentations des fonctionnalités et des interconnexions RAS, les serveurs horizontaux sont généralement moins chers par processeur.

Pour une architecture à trois niveaux, un bon exemple de haute disponibilité horizontale est le déploiement de serveurs Web. Vous pouvez déployer de nombreux petits serveurs, chacun avec une copie distincte du logiciel du serveur Web installée. Si un serveur Web tombe en panne, ses transactions sont redistribuées entre les serveurs sains restants. Dans le cas des serveurs d'applications, ils peuvent être hébergés sur des serveurs horizontaux et verticaux, et la haute disponibilité est obtenue grâce à la redondance. Qu'il s'agisse du déploiement de quelques grands serveurs SMP ou de nombreux petits serveurs, la redondance reste le principal moyen d'obtenir un RAS élevé au niveau des applications.

Cependant, au niveau des bases de données, la situation change. Les bases de données sont dynamiques et, de par leur nature, nécessitent, dans la plupart des cas, que les données soient partitionnées et accessibles depuis tous les processeurs/nœuds. Cela signifie que pour une haute disponibilité avec redondance, vous devez utiliser un logiciel de clustering tel que Sun Cluster ou Oracle9i RAC (pour une très haute disponibilité).

Conclusions

Les architectures verticales et horizontales ont leur place dans les centres de données d'aujourd'hui. Même si l'accent est aujourd'hui mis sur les nouvelles technologies telles que les serveurs modulaires et les bases de données parallèles, le marché reste très demandé pour les serveurs milieu et haut de gamme.

Les systèmes verticaux et horizontaux peuvent utiliser le même logiciel, le même système d'exploitation et même les mêmes processeurs. La principale différence qui affecte le prix et les performances réside dans les interconnexions utilisées dans chaque architecture. Les serveurs horizontaux utilisent des interconnexions externes faiblement couplées, tandis que les serveurs verticaux utilisent des interconnexions étroitement couplées qui offrent des taux de transfert de données plus élevés.

Pour le front-end, les serveurs horizontaux fournissent généralement la solution optimale en termes de performances, de coût total d'acquisition et de disponibilité. Pour la couche application, les architectures verticales et horizontales peuvent être utilisées efficacement. Pour la couche base de données, la solution optimale consiste à utiliser des serveurs verticaux, quel que soit le niveau de disponibilité requis.

Parmi les nombreuses fonctions d'un système d'information nécessaires à la gestion de la logistique en réseau, nous nous concentrerons d'abord sur deux fonctions clés « réseau » : la gestion des assortiments et le support à la gestion des catégories.

1. Gestion de l'assortiment dans une société de commerce en réseau.

Les entreprises de commerce de détail en réseau, en particulier dans le secteur alimentaire, se caractérisent par le plus haut niveau de complexité des tâches de gestion. La gestion des assortiments est un défi particulièrement difficile.

Mieux le problème est résolu, plus l'entreprise de commerce de détail dans son ensemble se développe efficacement et plus sa compétitivité est élevée.

La tâche de gestion de l'assortiment peut être divisée en deux sous-tâches – « externe » et « interne ».

Le premier vise à travailler avec l'acheteur en termes d'assortiment, le second vise à faciliter le travail du personnel avec les catégories d'assortiment.

Une solution réussie à ces problèmes devrait conduire à de meilleurs résultats de vente de produits.

Pour une solution efficace groupe de travail "externe" nécessaire:

• 1) fournir des informations sur les produits aux clients. Les systèmes d'information et de support multimédia sont conçus pour aider les clients à naviguer dans la mer infinie de marchandises, à faire le bon choix et à obtenir des informations précieuses dans les plus brefs délais. Dans le même temps, ils aident les détaillants à analyser les préférences des consommateurs, à stimuler la vente des biens nécessaires, à optimiser l'aménagement de la surface de vente, à placer rationnellement l'assortiment, ce qui garantit la solution réussie des tâches externes d'automatisation de la gestion de l'assortiment ;
• 2) résoudre des problèmes de marketing personnels. La mise en œuvre de la fonction marketing personnel est l'une des tâches les plus importantes de la gestion des assortiments pour les formats « supermarché » et « hypermarché ». De plus, si pour un supermarché il est très important de mener un marketing personnel ciblé en suivant les fluctuations des préférences de clients réguliers spécifiques d'un magasin donné, alors pour un hypermarché, il est important de travailler avec des groupes typiques de clients appartenant à une catégorie définie de manière conventionnelle. de clients réguliers. Quant aux discounters, le marketing personnel est moins pertinent pour eux. Pour identifier les préférences des clients réguliers, la disponibilité dans le système d'information de la capacité de procéder à une analyse complète des ventes et de déterminer la structure des achats est également une tâche extrêmement importante ;
• 3) réaliser un merchandising visuel de qualité. Une présentation efficace des marchandises sur les étagères des magasins augmente considérablement les volumes de ventes. Pour évaluer la qualité des solutions aux problèmes de visual merchandising, le système d'information doit être capable de maintenir et d'analyser des planogrammes qui décrivent le placement des marchandises dans les rayons des magasins.

Au moment de décider tâches de gestion des assortiments internes il est nécessaire d'automatiser les processus métier suivants :

1) processus de gestion active de l'assortiment (maintien des matrices d'assortiment).

Le fait est que les informations sur un produit, une fois saisies dans la base de données, y restent longtemps. Par exemple, avec un assortiment actuel de 7 000 articles, le système peut stocker 20 à 30 000 articles. Dans ces conditions, il est nécessaire de fournir à l'utilisateur du système la possibilité de travailler uniquement avec des informations actuelles sur l'assortiment actif (Fig. 3.4).

Riz. 3.4.

Pour résoudre ce problème, il faut assurer les fonctions suivantes :

• introduction de marchandises dans l'assortiment actif. Ce processus est généralement précédé d'une série d'activités de commercialisation d'essai avec un produit donné, de préparation de la logistique et de préparation avant-vente du produit ;
• cessation des achats de marchandises, comme première phase de retrait des marchandises de l'assortiment actif. Les raisons typiques de ce processus incluent :
  • a) insatisfaction à l'égard des résultats des ventes de produits ;
  • b) changement d'assortiment par le fabricant ;
  • c) présence de problèmes relationnels avec le fournisseur ; etc.;
• cessation du réapprovisionnement des stocks du centre de distribution de l'entreprise ;
• cessation du travail avec le produit, comme phase finale de retrait du produit de l'assortiment dans l'information

système (se produit généralement lorsque les réserves atteignent zéro) ;

Suppression des informations sur les marchandises sur les systèmes de caisse enregistreuse (généralement effectuée après l'inventaire).

Avantages de l'automatisation de ce processus métier :

• commodité pour les utilisateurs lorsqu'ils travaillent avec la gamme de produits ;
• une réduction significative du nombre d'erreurs liées à l'impossibilité d'inclure dans les documents des produits n'appartenant pas à l'assortiment actif ;
• la possibilité de recevoir des rapports analytiques uniquement sur l'assortiment actif ;
• augmenter la productivité des gestionnaires impliqués dans la gestion des assortiments ; etc.;
• 2) le processus de gestion d'un assortiment actif d'entreprises de vente au détail de divers formats , inclus dans une entreprise commerciale en réseau multiformat (gestion de plusieurs matrices d'assortiment).

L'automatisation de ce processus métier permet d'empêcher le mouvement des marchandises vers un objet de gestion, aux matrices d'assortiment dont ce produit n'appartient pas (Fig. 3.5).

Riz. 3.5.

Il convient également de noter qu'une solution de haute qualité aux problèmes de gestion « interne » des assortiments est de la plus haute importance pour une entreprise de commerce de détail en réseau multiformat.

2. Processus de support à la gestion des catégories grâce à la formation de vues de produits et de vues d'objets de gestion avec lesquels travaille un gestionnaire de catégorie spécifique.

Pour un manager impliqué dans la gestion de catégories de produits spécifiques, regroupées en unités commerciales dites stratégiques, lorsqu'il travaille avec un système d'information, il est important de se concentrer sur un certain sous-ensemble de produits et d'objets de gestion.

Il convient qu'un Category Manager ne voie que ce qui concerne « ses catégories de produits » afin de créer l'illusion qu'il n'y a rien dans le système d'information à l'exception des biens inclus dans son business unit et des objets de gestion dont il est responsable.

Il est nécessaire pour le manager de créer des perspectives sur les flux de produits qui présenteraient les informations logistiques et analytiques à travers le prisme de la business unit stratégique avec laquelle il travaille dans le cadre de ses fonctions.

Pour assurer le travail avec le système d'information dans ce mode, celui-ci doit mettre en œuvre la possibilité d'attribuer des vues produits et des vues des objets de gestion.

Dans le même temps, il existe au moins deux types fondamentaux de vues de produits : statiques et dynamiques.

Chaque manager a sa propre perspective produit, qui définit son unité commerciale stratégique. Dans ce cas, les responsables responsables d’une même unité commerciale se voient attribuer une seule vue.

Dans le cas de la définition d'une vue produit statique, un ensemble de produits est en fait enregistré sous forme de liste nommée (Fig. 3.6). C'est pratique pour fixer strictement un ensemble (par exemple, pour une analyse).

Riz. 3.6.

Afin d'administrer efficacement les vues produits pour définir les unités commerciales, il est préférable de les définir sur les nœuds du classificateur de produits. Appelons ces vues dynamiques (Fig. 3.7).

Riz. 3.7.

Dans ce cas, dès qu'un nouveau produit est introduit dans un sous-groupe spécifique, inclus dans la perspective dynamique du gestionnaire de catégorie, il devient automatiquement un élément de l'unité commerciale stratégique et le responsable commence rapidement à travailler avec lui.

Lorsqu'un produit est déplacé vers un autre sous-groupe (par exemple, en raison d'un changement de catégorisation), il est déplacé vers une autre unité commerciale stratégique et est automatiquement transféré vers un autre gestionnaire de catégories pour le travail.

La vue des objets de gestion est formée de la même manière - il s'agit d'une vue statique qui définit la liste des magasins et des centres de distribution au sein desquels un gestionnaire de catégorie spécifique opère (Fig. 3.8).

Riz. 3.8.

Cette approche permet aux utilisateurs du système, y compris les fabricants ou les fournisseurs de biens, d'accéder aux informations et aux fonctions nécessaires du système d'information au sein d'un certain sous-ensemble de la gamme de produits active et des objets commerciaux correspondants.

Cette fonction est très importante lors de la mise en œuvre du concept logistique VMI, lorsqu'un fournisseur ou un fabricant est impliqué dans la gestion de la chaîne d'approvisionnement de « leurs » marchandises.

En conclusion, formulons plusieurs conclusions de ce qui précède :

• 1) la gestion de l'assortiment d'une entreprise commerciale est la tâche la plus importante, dont la qualité de la solution détermine directement son succès ;
• 2) les solutions au groupe externe des problèmes de gestion des assortiments, en particulier les entreprises de vente au détail de grand format, sont conçues pour fournir des systèmes d'information client (kiosques d'information, terminaux multimédias, chariots d'information, etc.) ;
• 3) la capacité de conserver des matrices d'assortiment, des vues de produits et des vues d'objets de gestion dans le système d'information facilite la capacité à résoudre un groupe interne de tâches de gestion d'assortiment, qui est directement lié à la qualité de la mise en œuvre de la fonction de gestion des catégories dans une entreprise commerciale .

Évolutivité du système d’information

Lors du développement d'une entreprise de vente au détail en réseau, il arrive parfois un moment où le système d'information ne peut plus soutenir la croissance future de l'entreprise. La question de l’adéquation du système d’information à la croissance de l’entreprise est donc extrêmement importante.

Dans ce cas, deux aspects doivent être pris en compte : l'adéquation à la croissance et l'évolutivité du système.

Si la croissance d’une entreprise s’accompagne d’une augmentation disproportionnée des coûts de l’infrastructure informatique, alors le système d’information n’est pas en mesure de soutenir de manière optimale l’expansion de l’entreprise.

Des systèmes d'information inadaptés à la croissance de l'entreprise peuvent entraîner une augmentation accélérée des coûts de leur fonctionnement.

Tout d’abord, l’architecture de la solution doit correspondre à la croissance de l’entreprise. Lorsqu'une entreprise se développe et possède des centaines d'installations, construire un système sur une architecture distribuée signifie, à notre avis, faire face à une augmentation toujours croissante des coûts de support informatique par magasin.

Dans le contexte d'une entreprise en réseau qui gère une centaine de points de vente, la synchronisation des données avec leur consolidation ultérieure dans le centre devient de plus en plus difficile et il arrive un moment où cela devient impossible.

Pour assurer l'évolutivité du système d'information (la capacité de fournir le nombre requis d'utilisateurs, de fonctionner avec la quantité d'informations requise avec des performances satisfaisantes), il est nécessaire de choisir la bonne plate-forme - un logiciel et un matériel serveur appropriés.

Si une entreprise de vente au détail est en croissance, le volume d'informations sur les ventes n'est pas calculé en gigaoctets, mais en téraoctets, et cela ne peut se faire sans l'utilisation de systèmes de gestion de bases de données « industriels » et évolutifs tels qu'Oracle, Progress, etc.

Des systèmes d'exploitation seront également nécessaires, à l'aide desquels il serait possible de « migrer » vers une autre classe d'équipements informatiques.

Il est évident que lors du choix d'un système d'information et de son exploitation, les enseignes de distribution dont la stratégie implique une croissance rapide doivent réfléchir sérieusement à l'évolutivité et au coût de possession du système d'information.

Nous sommes convaincus qu'à mesure qu'une entreprise se développe, l'architecture distribuée devient un obstacle colossal à la réduction des coûts de gestion de l'entreprise et d'exploitation de l'infrastructure informatique.

L'architecture centralisée du système d'information implique un coût de possession inférieur et ne nécessite pas une augmentation constante du nombre de personnel informatique à mesure que le réseau de vente au détail se développe.

L'évolutivité des systèmes d'entreprise signifie la possibilité d'augmenter leur puissance en connectant de nouveaux matériels et logiciels sans modification supplémentaire de ces derniers. Ce point est important lors de l’utilisation de technologies informatiques et réseau modernes. Un exemple peut être donné du traitement distribué des données dans une banque centrale et ses succursales.

L'évolutivité est atteinte à différents niveaux : a) technique ; b) systémique ; c) Réseau ; d) SGBD ; d) Appliqué. Pour un système d'exploitation, l'évolutivité signifie que le système d'exploitation n'est pas lié à une architecture de processeur unique. Si les tâches auxquelles l'utilisateur est confronté deviennent plus complexes et que les exigences imposées au réseau informatique augmentent, le système d'exploitation doit offrir la possibilité d'ajouter des serveurs et des postes de travail plus puissants et plus productifs au réseau d'entreprise. Vous pouvez considérer l’évolutivité du matériel, des logiciels et l’évolutivité du système dans son ensemble. L'évolutivité repose sur des technologies telles que : a) les normes internationales ; b) Technologies de réseaux et de télécommunications ; c) Systèmes d'exploitation ; d) Technologie client/serveur et un certain nombre d'autres moyens.

Fin des travaux -

Ce sujet appartient à la section :

Technologies de l'information informatique en gestion. Classification des systèmes de contrôle

Le but du CIS est de préparer à l'utilisation des technologies de l'information modernes dans le cadre du CIS comme outil pour résoudre des problèmes scientifiques et pratiques dans.. Le concept de technologie de l'information Information d'entreprise..

Si vous avez besoin de matériel supplémentaire sur ce sujet, ou si vous n'avez pas trouvé ce que vous cherchiez, nous vous recommandons d'utiliser la recherche dans notre base de données d'œuvres :

Que ferons-nous du matériel reçu :

Si ce matériel vous a été utile, vous pouvez l'enregistrer sur votre page sur les réseaux sociaux :

Tweeter

Tous les sujets de cette section :

Notion de technologie de l’information. Technologies de l’information d’entreprise
La technologie est un système de méthodes interconnectées de traitement des matériaux et de méthodes de fabrication de produits dans le processus de production. La technologie de l'information est un système de technologies interconnectées

Technologie de traitement de l'information. Concept d’interopérabilité, d’ouverture et de modularité
L'information est un ensemble de faits, phénomènes, événements intéressants qui font l'objet d'un enregistrement et d'un traitement. Cela implique la présence de deux points : la source et le récepteur (consommateur) de l'information

Types de support des systèmes d’information
Types de soutien ASOEI : a) Technique ; b) Mathématiques ; c) linguistique ; d) Logiciel. Support d'information – système de classification et de codage de l'information, schéma technologique de traitement

Architecture d'un système d'information d'entreprise
L'architecture du CIS se compose de plusieurs niveaux : a) Niveau informationnel-logique – est un ensemble de flux de données et de centres (nœuds) d'origine, de consommation

Exigences pour les systèmes d'information d'entreprise
Les processus d'amélioration active des technologies de traitement de l'information sont une conséquence du fait que les exigences suivantes sont de plus en plus imposées aux systèmes d'information modernes (CIS) : a) structure

Hétérogénéité des systèmes d'information des entreprises. Solutions aux problèmes d’hétérogénéité des systèmes d’information des entreprises
Le rôle le plus important est joué par la résolution des problèmes d'hétérogénéité des systèmes d'entreprise et la garantie de la compatibilité des composants qui le composent. L'hétérogénéité des systèmes informatiques peut entraîner

Normes internationales dans le domaine des technologies de l'information informatique
Actuellement, un ensemble de normes pour un système qualité d'entreprise développé par l'ISO (Organisation internationale de normalisation), ou plus précisément par le comité technique de l'ISO, s'est répandu dans le monde entier.

Modèles d'information de l'objet de contrôle
Une entreprise moderne peut être considérée comme un centre d'information efficace, dont les sources d'informations sont l'environnement commercial externe et interne. Environnement commercial externe –

Support informationnel pour les systèmes d'information d'entreprise
Support d'information – un système de classification et de codage des informations, un schéma technologique de traitement des données, des informations réglementaires et de référence, un système de flux de documents, etc. Informatif

Politique de formation de ressources d'information en tant qu'espace d'information unique
Pour assurer l'interaction des ressources informationnelles à différents niveaux, il est nécessaire : a) L'utilisation des technologies de l'information modernes ; b) Environnement moderne de l'information sur les transports ; c) Manger

Avantages de l'utilisation de systèmes informatiques
Grâce à l'utilisation d'ordinateurs multi-machines et multi-processeurs, il est possible d'obtenir les avantages suivants : 1) Productivité et vitesse accrues

Matériel de communication et matériel de communication
Les technologies de la communication assurent l'une des fonctions principales des activités de gestion - le transfert d'informations au sein du système de gestion et l'échange de données avec l'environnement externe, suggèrent

Systèmes d'exploitation (OS). Technologies du système d'exploitation
Parmi les programmes système, le système d'exploitation (OS) occupe une place particulière. Le système d'exploitation (OS) est compris comme un ensemble de programmes qui gèrent

OS Unix et solutions structurelles dans les systèmes d'information d'entreprise. Notion de mobilité
Le développement du système d'exploitation Unix a commencé avec les laboratoires Bell en 1968. Un système d'exploitation Unix 32 bits multi-utilisateurs pour Main Frame a été proposé. En 1976, AT&T (qui comprenait B

Le concept de réseaux informatiques et leurs caractéristiques
Un réseau informatique est un complexe d'ordinateurs géographiquement dispersés, interconnectés par des canaux de transmission de données pour une utilisation efficace des ressources informatiques. Faisabilité

Composition des réseaux informatiques
Les réseaux informatiques comprennent du matériel, des logiciels et des outils d'information. Autrement dit, un réseau informatique peut être considéré comme un système doté de matériel et de logiciels répartis sur tout le territoire.

Architecture du réseau informatique
De manière générale, l'architecture des réseaux informatiques peut être envisagée sous deux points de vue : l'organisation physique d'un réseau informatique (topologie du réseau) et l'organisation du réseau au niveau logique.

Réseaux informatiques avec serveur dédié et leurs caractéristiques
Le client-serveur est une architecture réseau dans laquelle les appareils sont soit des clients, soit des serveurs. Le client est la machine qui demande (généralement un PC), le serveur est la machine qui répond.

Structure des réseaux informatiques mondiaux
Les réseaux mondiaux (WAN, Wide Area Networks) sont des systèmes dotés de canaux haut débit et permettent d'organiser l'interaction entre ordinateurs sur de longues distances. Idéalement, un ordinateur mondial

Évolutivité des réseaux informatiques
Évolutivité – la capacité d'augmenter les ressources réseau et le nombre d'abonnés. Dans les réseaux informatiques dotés d'un serveur dédié, les postes de travail sont connectés à des serveurs dédiés, et les serveurs, à leur tour, sont regroupés

Protocoles Internet
Le protocole dans ce cas est, au sens figuré, le « langage » utilisé par les ordinateurs pour échanger des données lorsqu'ils travaillent sur un réseau. Pour que différents ordinateurs d'un réseau puissent communiquer, ils doivent communiquer

Adressage Internet
Internet est un système mondial de réseaux informatiques interconnectés, construit sur l'utilisation du protocole IP et le routage des paquets de données. Internet constitue un espace d'information mondial, au service

L'évolutivité est une propriété d'un système informatique qui permet une croissance prévisible des caractéristiques du système, par exemple le nombre d'utilisateurs pris en charge, la vitesse de réponse, les performances globales, etc., lorsque des ressources informatiques y sont ajoutées. Dans le cas d'un serveur SGBD, deux méthodes de mise à l'échelle peuvent être envisagées : verticale et horizontale (Fig. 2).

Avec la mise à l'échelle horizontale, le nombre de serveurs SGBD augmente, communiquant éventuellement entre eux de manière transparente, partageant ainsi la charge globale du système. Cette solution est susceptible de devenir de plus en plus populaire à mesure que la prise en charge des architectures faiblement couplées et des bases de données distribuées se développe, mais elle tend à être difficile à administrer.

La mise à l'échelle verticale implique d'augmenter la puissance d'un serveur SGBD distinct et est obtenue en remplaçant le matériel (processeur, disques) par des plus rapides ou en ajoutant des nœuds supplémentaires. Un bon exemple est l’augmentation du nombre de processeurs dans les plates-formes multiprocesseurs symétriques (SMP). Dans ce cas, le logiciel du serveur ne doit pas être modifié (en particulier, l'achat de modules supplémentaires ne peut pas être requis), car cela augmenterait la complexité de l'administration et aggraverait la prévisibilité du comportement du système. Quelle que soit la méthode de mise à l'échelle utilisée, le gain est déterminé par la mesure dans laquelle les programmes serveur utilisent les ressources informatiques disponibles. Dans des évaluations plus approfondies, nous considérerons la mise à l'échelle verticale, qui, selon les analystes, connaît la plus forte croissance sur le marché informatique moderne.

La propriété d'évolutivité est pertinente pour deux raisons principales. Tout d’abord, les conditions commerciales modernes évoluent si rapidement qu’elles rendent impossible la planification à long terme, qui nécessite une analyse complète et longue de données déjà obsolètes, même pour les organisations qui en ont les moyens. En retour, une stratégie d’augmentation progressive, étape par étape, de la puissance des systèmes d’information. D’autre part, les évolutions technologiques conduisent à l’émergence de solutions toujours plus nouvelles et à une baisse des prix du matériel, ce qui rend potentiellement l’architecture des systèmes d’information plus flexible. Dans le même temps, l'interopérabilité et l'ouverture des produits logiciels et matériels de différents fabricants se développent, même si jusqu'à présent leurs efforts pour se conformer aux normes n'ont été coordonnés que dans des secteurs restreints du marché. Sans prendre en compte ces facteurs, le consommateur ne pourra pas profiter des nouvelles technologies sans geler les fonds investis dans des technologies pas assez ouvertes ou qui se sont révélées peu prometteuses. Dans le domaine du stockage et du traitement des données, cela nécessite que le SGBD ainsi que le serveur soient évolutifs. Aujourd’hui, les paramètres clés d’évolutivité sont :

• prise en charge du multitraitement ;
• flexibilité architecturale.

Systèmes multiprocesseurs

Pour la mise à l'échelle verticale, les systèmes multiprocesseurs symétriques (SMP) sont de plus en plus utilisés, car dans ce cas, il n'est pas nécessaire de changer de plate-forme, c'est-à-dire compétences en matière de système d’exploitation, de matériel et d’administration. À cette fin, il est également possible d'utiliser des systèmes à parallélisme massif (MPP), mais jusqu'à présent, leur utilisation est limitée à des tâches spéciales, par exemple informatiques. Lors de l'évaluation d'un serveur SGBD à architecture parallèle, il convient de prêter attention à deux caractéristiques principales de l'extensibilité de l'architecture : l'adéquation et la transparence.

La propriété d'adéquation nécessite que l'architecture du serveur prenne également en charge un ou dix processeurs sans réinstallation ni modification significative de la configuration, ainsi que des modules logiciels supplémentaires. Une telle architecture sera également utile et efficace à la fois dans un système monoprocesseur et, à mesure que la complexité des tâches à résoudre augmente, sur plusieurs voire plusieurs processeurs (MPP). En général, le consommateur n'a pas besoin d'acheter ou d'apprendre de nouvelles options logicielles.

Fournir de la transparence à l'architecture du serveur permet, à son tour, de masquer les modifications de configuration matérielle des applications, c'est-à-dire garantit la portabilité des systèmes logiciels d’application. En particulier, dans les architectures multiprocesseurs étroitement couplées, l'application peut communiquer avec le serveur via un segment de mémoire partagée, tandis que dans les systèmes multiserveurs (clusters) faiblement couplés, un mécanisme de message peut être utilisé à cette fin. L'application ne doit pas prendre en compte les capacités de mise en œuvre de l'architecture matérielle - les méthodes de manipulation des données et l'interface logicielle d'accès à la base de données doivent rester les mêmes et tout aussi efficaces.

Une prise en charge de haute qualité du multitraitement nécessite que le serveur de base de données soit capable de planifier indépendamment l'exécution de nombreuses requêtes à traiter, ce qui garantirait la répartition la plus complète des ressources informatiques disponibles entre les tâches du serveur. Les demandes peuvent être traitées séquentiellement par plusieurs tâches ou divisées en sous-tâches, qui, à leur tour, peuvent être exécutées en parallèle (Fig. 3). Ce dernier est plus optimal car une bonne mise en œuvre de ce mécanisme offre des avantages indépendants des types de requêtes et des applications. L'efficacité du traitement est fortement influencée par le niveau de granularité des opérations prises en compte par la tâche du planificateur. Avec une granularité grossière, par exemple au niveau des requêtes SQL individuelles, la répartition des ressources du système informatique (processeurs, mémoire, disques) ne sera pas optimale - la tâche sera inactive, en attendant la fin des opérations d'E/S nécessaires pour terminer la requête SQL, au moins dans la file d'attente. Il y avait d'autres requêtes qui nécessitaient un travail de calcul important. Avec une granularité plus fine, la division des ressources se produit même au sein d'une seule requête SQL, ce qui est encore plus évident lorsque plusieurs requêtes sont traitées en parallèle. L'utilisation d'un planificateur garantit que d'importantes ressources système sont utilisées pour résoudre les tâches de maintenance réelles de la base de données et minimise les temps d'arrêt.

Flexibilité architecturale

Quels que soient le degré de portabilité, la prise en charge des normes, le parallélisme et d'autres qualités utiles, les performances d'un SGBD, qui présente des limitations architecturales intégrées tangibles, ne peuvent pas être augmentées librement. La présence de restrictions documentées ou pratiques sur le nombre et la taille des objets de base de données et des tampons mémoire, le nombre de connexions simultanées, sur la profondeur de récursion des procédures d'appel et des sous-requêtes ou sur le déclenchement des déclencheurs de base de données est la même limitation sur l'applicabilité du SGBD, comme comme par exemple l’impossibilité de transférer vers plusieurs plateformes informatiques. Les paramètres qui limitent la complexité des requêtes de base de données, notamment la taille des tampons dynamiques et la taille de la pile pour les appels récursifs, doivent être configurables dynamiquement et ne pas nécessiter l'arrêt du système pour reconfiguration. Il ne sert à rien d'acheter un nouveau serveur puissant si les attentes ne peuvent être satisfaites en raison des limitations internes du SGBD.

Généralement, le goulot d'étranglement réside dans l'incapacité d'ajuster dynamiquement les caractéristiques des programmes du serveur de base de données. Possibilité de déterminer à la volée des paramètres tels que la quantité de mémoire consommée, le nombre de processeurs occupés, le nombre de threads de travail parallèles (qu'il s'agisse de threads réels, de processus du système d'exploitation ou de processeurs virtuels) et le nombre de fragments de tables de base de données et les index, ainsi que leur distribution sur des disques physiques SANS arrêter ni redémarrer le système est une exigence découlant de l'essence des applications modernes. Idéalement, chacun de ces paramètres pourrait être modifié de manière dynamique dans les limites spécifiques à l'utilisateur.