Dans cette série d'articles, j'aimerais présenter et discuter de plusieurs approches possibles pour le développement de logiciels avec les technologies d'InterSystems et GitLab. J'aborderai des sujets tels que:

• Git 101
• Le flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD

Dans l'article précédent, nous avons évoqué les notions de base de Git, les raisons pour lesquelles une compréhension approfondie des concepts de Git est importante pour le développement de logiciels modernes et la manière dont Git peut être utilisé pour développer des logiciels. Et bien que nous nous soyons concentrés sur la partie mise en œuvre du développement de logiciels, cette partie présente :

• Le flux de travail GitLab est un processus complet du cycle de vie d'un logiciel, allant de l'idée au retour utilisateur
• Diffusion continue est une approche d'ingénierie logicielle dans laquelle les équipes produisent des logiciels en cycles courts, garantissant que le logiciel peut être diffusé de manière fiable à tout moment. Elle vise à créer, tester et publier des logiciels plus rapidement et plus fréquemment.

Tout le monde dispose d'un environnement de test.

Certains ont la chance de disposer d'un environnement totalement séparé pour la production.

-- Inconnu

.

Dans cette série d'articles, j'aimerais présenter et discuter de plusieurs approches possibles pour le développement de logiciels avec les technologies d'InterSystems et GitLab. J'aborderai des sujets tels que:

• Git 101
• Git flow (processus de développement)
• Installation de GitLab
• Flux de travail GitLab WorkFlow
• GitLab CI/CD
• CI/CD avec des conteneurs

Cette première partie traite de la pierre angulaire du développement logiciel moderne - le système de contrôle de version Git et divers flux Git.

Rubrique Questions fréquentes (FAQ) d'InterSystems

Pour les routines (*.mac)

Vous pouvez masquer la source en exportant/important uniquement le fichier *.obj généré après la compilation du programme source.

L'exemple d'exécution de la commande spécifie EX1Sample.obj et EX2Sample.obj, qui sont générés par la compilation de EX1Sample.mac et EX2Sample.mac, comme cibles d'exportation et les exporte dans le deuxième fichier argument.

Après avoir changé d'espace de noms, j'utilise le fichier XML exporté pour effectuer l'importation.

Salut,

Je suis vraiment nouveau sur le sujet de JWT, alors s'il vous plaît, veuillez pardonner mon ignorance.

Le Trust pour lequel je travaille actuellement souhaite créer un cadre dans lequel ils peuvent créer des services API REST, au sein de HealthConnect, et y accorder l'accès à l'aide de l'autorisation de jeton Web JSON et des porteurs de jetons. Cela serait similaire à la manière dont le Trust se connecte actuellement à d'autres API REST, à savoir : DocMan Connect et GOV.UK Notify.

Actuellement, les privilèges SQL (SELECT, INSERT, UPDATE, DELETE) sont gérés au niveau des tables, ce qui peut s'avérer très fastidieux lorsque vous devez administrer de nombreux rôles dans une organisation et les synchroniser avec des modèles de données en constante évolution.
En gérant les privilèges au niveau des schémas, cela permettra d'accorder des privilèges SELECT et d'autres privilèges DML à *tous* ou *plusieurs schémas* à un rôle|utilisateur, corrigeant ainsi le besoin de synchroniser manuellement les nouvelles tables|vues avec les rôles.

Bonjour,

J'ai une globale dont la structure est à plusieurs niveaux et j'essaie à travers une class et une requête SQL d'afficher un tableau qui comprend toutes les valeurs et les niveaux.

^AFO("Site","Ville")="66722,3743"
^AFO("Site","Ville","111BB","OBT")=",MMM,XXX,"
^AFO("Site","Ville","111OW","OBT")=",XXX,MMM,"
^AFO("Site","Ville","AANVRBIBS","zzz")    =    "1^^1"
^AFO("Site","Ville","AANVRBIBS","zzz","*","dut")    =    "*afhalen waar gevonden"
^AFO("Site","Ville","AANVRBIBS","zzz","*","eng")    =    "*Pickup where found"
^AFO("Site","Ville","AANVRBIBS","zzz","*","fre")    =    "*Lieu où trouvé"

pour démonter/monter une base de données, utilisez les méthodes Dismount() et Mount() dans la classe SYS.Database disponible dans l'espace de noms %SYS.
NB : l'ID de la base de données est le nom du chemin absolu de son répertoire.

Vous trouverez quelques exemples de démontage/montage et de méthodes contrôlant si une base de données est montée (Mounted=1) ou non (Mounted=0), ou affichant rapidement tous les attributs d'une base de données (via zwrite)

Je travaille avec des clients qui envisagent de migrer de Caché vers IRIS et je souhaite résumer les avantages d'aller vers IRIS. Je pense à ceux-ci:

1. IntegratedML - AutoML - Agile machine learning
2. IAM - InterSystems API Manager
3. Interopérabilité
4. Advanced Reports (JReport)
5. Cloud Manager/Docker et support DevOps
6. ZPM - Package manager
7. Native API - Node.js, Python, Java and .NET interoperability
8. Licence basée sur le cœur x licence basée sur l'utilisateur
9. Support InterSystems et nouvelles fonctionnalités
10. Fonctionnalités de gestion et de surveillance améliorées

À l'installation d'IRIS, tous les événements d'AUDIT système ne sont pas activés.

Quel est le moyen le plus rapide pour activer tous les événements ?

 Système > Gestion de la sécurité > Événements d'audit système 

Bonjour les développeurs, Je suis actuellement en train de faire une démo sur la construction d'une interface utilisateur en front-end faisant de l'analyse de données et de mettre en place un test de performance avec de gros objets de données, donc l'utilisation de "Populate Utility" pourrait m'aider à générer automatiquement des échantillons de données avec lesquels je pourrais jouer.

Dans ce post, j'aimerais partager mon expérience de l'utilisation de Populate Utility, y compris l'utilisation du paramètre POPSPEC.

1. Pour commencer, j'ai créé 2 classes persistantes pour soutenir l'utilitaire "Populate Utility" ( Extends (%Persistent, %Populate)) : popPatient qui a pour but de remplir les informations sur les patients, popSign pour simuler les données collectées à partir d'un capteur de rythme cardiaque sur le patient.   

2.1 Pour que cette démo soit plus proche de la réalité, j'aimerais ajouter la plage de valeurs des variables pour certaines propriétés en utilisant MAXVAL et MINVAL. Par exemple, vous ne pouvez pas vous attendre à ce que l'âge d'un patient soit de 1000 ans.

Faire la même chose pour le rythme cardiaque

2.2 Si nous devons utiliser une méthode de génération automatique personnalisée, il nous faut cette fois utiliser POPSPEC pour définir les valeurs générées，par exemple Nous avons des classes prédéfinies qui peuvent être référencées directement et qui génèrent des numéros de téléphone américains, mais dans mon cas, je veux générer un format qui corresponde au numéro de téléphone australien. Je souhaite également enregistrer l'heure des rythmes cardiaques collectées et créer une liste pour y placer toutes les valeurs que je souhaite générer. Tout ce qui précède doit utiliser POPSPEC pour personnaliser la génération de données à partir d'une méthode définie par l'utilisateur.

Dans ce cas, j'ai écrit deux méthodes de classe simples pour prédéfinir le format du numéro de téléphone et récupérer l'horodatage actuel en tant qu'heure de collecte du rythme cardiaque. Ensuite, j'ai ajouté le paramètre POPSPEC à la propriété correspondante

3. Exécution de la méthode et démarrage de l'alimentation des données

Vous pouvez simplement saisir la commande suivante dans Terminal pour alimenter les données, en remplaçant number par le nombre de valeurs à alimenter.

"do ##class(Demo.popPatient).Populate( number  )"

"do ##class(Demo.popSign).Populate( number )"

Ou vous pouvez placer ces deux commandes définies dans une classMethod comme ceci, puis exécuter "do ##class(Demo.RunPopulate). StartPop ('temps pour le patient', temps pour les signes')

4.Voici un exemple de génération de 10 patients et de 50 signes de rythme cardiaque collectés

J'espère que cette explication simple pourra vous aider, Bon codage !

Rubrique FAQ InterSystems

Vous pouvez voir l'espace disponible libre pour la base de données à l'aide du bouton radio « Vue de l'espace libre » dans le portail de gestion : Exploitation du système > Bases de données.

Et il peut être obtenu par programmation par la requête FreeSpace de la classe système SYS.Database.

Salut,

Dans une application CSP de Caché, j'ai activé les jours d'expiration du mot de passe à certains jours dans Système > Gestion de la sécurité > Paramètres de sécurité de niveau système. Lorsque le mot de passe expire pour les utilisateurs et qu'ils tentent de se connecter, la page de connexion passe à la page de modification du mot de passe du cache standard.

Puis-je afficher ma page personnalisée au lieu de la page de modification du mot de passe standard de Caché ?

Il arrive parfois que suite à un événement indésirable la base d'AUDIT (IRISAUDIT) ait pris des proportions telles que le disque sur lequel elle réside soit plein et qu'on ne peut attendre la purge quotidienne pour récupérer l'espace disque.

Salut,

Pour la connexion à l'application CSP, j'affiche une page de connexion personnalisée qui est rendue à partir de la sous-classe CSS.CSP.Login qui hérite de %CSP.Login, et j'ai également IBA.CSP.Page qui étend %CSP.Page en surchargeant OnPreHTTP(). Cette configuration fonctionne parfaitement pour une connexion normale.

Les entreprises doivent développer et gérer leurs infrastructures informatiques mondiales rapidement et efficacement tout en optimisant et en gérant les coûts et les dépenses d'investissement. Les services de calcul et de stockage Amazon Web Services (AWS) et Elastic Compute Cloud (EC2) couvrent les besoins des applications les plus exigeantes basées sur Caché en fournissant une infrastructure informatique mondiale très robuste. L'infrastructure Amazon EC2 permet aux entreprises de provisionner rapidement leur capacité de calcul et/ou d'étendre rapidement et de manière flexible leur infrastructure sur site existante dans le cloud. AWS fournit un riche ensemble de services et des mécanismes robustes, de niveau entreprise, pour la sécurité, la mise en réseau, le calcul et le stockage.

AAmazon EC2 est au cœur d'AWS. Une infrastructure de cloud computing qui prend en charge une variété de systèmes d'exploitation et de configurations de machines (par exemple, CPU, RAM, réseau). AWS fournit des images de machines virtuelles (VM) préconfigurées, appelées Amazon Machine Images ou AMI, avec des systèmes d'exploitation hôtes comprenant diverses distributions et versions de Linux® et de Windows. Ils peuvent avoir des logiciels supplémentaires utilisés comme base pour les instances virtualisées fonctionnant dans AWS. Vous pouvez utiliser ces AMI comme points de départ pour installer ou configurer des logiciels, des données et d'autres éléments supplémentaires afin de créer des AMI spécifiques aux applications ou aux charges de travail. 

Comme pour toute plate-forme ou tout modèle de déploiement, il faut veiller à prendre en compte tous les aspects d'un environnement applicatif, tels que les performances, la disponibilité, les opérations et les procédures de gestion. 

Ce document traite des spécificités de chacun des domaines suivants.

• • Installation et configuration du réseau. Cette section couvre la configuration du réseau pour les applications basées sur Caché dans AWS, y compris les sous-réseaux pour prendre en charge les groupes de serveurs logiques pour les différentes couches et rôles dans l'architecture de référence.
• • Installation et configuration du serveur. Cette section couvre les services et les ressources impliqués dans la conception des différents serveurs pour chaque couche. Il comprend également l'architecture pour la haute disponibilité à travers les zones de disponibilité.
• • Sécurité. Cette section aborde les mécanismes de sécurité dans AWS, notamment la manière de configurer l'instance et la sécurité du réseau pour permettre un accès autorisé à la solution globale ainsi qu'entre les couches et les instances.
• • Déploiement et gestion. Cette section fournit des détails sur la décompression, le déploiement, la surveillance et la gestion. 

Scénarios d'architecture et de déploiement

Ce document présente plusieurs architectures de référence au sein d'AWS à titre d'exemples pour fournir des applications robustes, performantes et hautement disponibles basées sur les technologies InterSystems, notamment Caché, Ensemble, HealthShare, TrakCare, et les technologies embarquées associées telles que DeepSee, iKnow, CSP, Zen et Zen Mojo.

Pour comprendre comment Caché et les composants associés peuvent être hébergés sur AWS, examinons d'abord l'architecture et les composants d'un déploiement typique de Caché et explorons quelques scénarios et topologies courants.

Revue d'Architecture Caché

La plate-forme de données d'InterSystems évolue en permanence pour fournir un système de gestion de base de données avancé et un environnement de développement rapide d'applications permettant de réaliser des percées dans le traitement et l'analyse de modèles de données complexes et de développer des applications Web et mobiles.

Il s'agit d'une nouvelle génération de technologie de base de données qui offre de multiples modes d'accès aux données. Les données sont uniquement décrites dans un dictionnaire de données intégré unique et sont instantanément disponibles en utilisant l'accès aux objets, le SQL ¬haute performance et l'accès multidimensionnel puissant - qui peuvent tous accéder simultanément aux mêmes données.

La Figure-1 présente les niveaux de composants et les services disponibles dans l'architecture de haut niveau Caché. Ces niveaux généraux s'appliquent également aux produits InterSystems TrakCare et HealthShare.

Figure 1 : Niveaux de composants de haut niveau

Scénarios de déploiement courants

There are numerous combinations possible for deployment, however in this document two scenarios will be covered; a hybrid model and complete cloud hosted model. 

Hybrid Model

Dans ce scénario, une entreprise souhaite exploiter à la fois les ressources d'entreprise sur site et les ressources AWS EC2 pour la reprise après sinistre, les imprévus de maintenance interne, les initiatives de replatformage ou l'augmentation de la capacité à court ou à long terme, le cas échéant. Ce modèle peut offrir un niveau élevé de disponibilité pour la continuité des activités et la reprise après sinistre pour un ensemble de membres miroir de basculement sur site. 

La connectivité pour ce modèle dans ce scénario est basée sur un tunnel VPN entre le déploiement sur site et la ou les zones de disponibilité AWS pour présenter les ressources AWS comme une extension du centre de données de l'entreprise. Il existe d'autres méthodes de connectivité telles que AWS Direct Connect. Cependant, cela n'est pas couvert dans le cadre de ce document. Vous trouverez plus de détails sur AWS Direct Connect ici.

Les détails de la configuration de cet exemple d'Amazon Virtual Private Cloud (VPC) pour soutenir la reprise après sinistre de votre centre de données sur¬ site peuvent être trouvés ici.

Figure 2 : Modèle hybride utilisant AWS VPC pour la reprise après sinistre sur site

L'exemple ci-dessus montre une paire de miroirs de basculement fonctionnant dans votre centre de données sur site avec une connexion VPN à votre VPC AWS. Le VPC illustré fournit plusieurs sous-réseaux dans des zones de disponibilité doubles dans une région AWS donnée. Il existe deux membres miroirs asynchrones de reprise après sinistre (DR) (un dans chaque zone de disponibilité) pour assurer la résilience.  

Modèle hébergé dans le cloud

Dans ce scénario, votre application basée sur le Cache, y compris les couches de données et de présentation, est entièrement conservée dans le cloud AWS en utilisant plusieurs zones de disponibilité au sein d'une même région AWS. Les mêmes modèles de tunnel VPN, AWS Direct Connect et même de connectivité Internet pure sont disponibles.

Figure 3 : Modèle hébergé dans le cloud prenant en charge la totalité de la charge de travail de production

L'exemple de la Figure-3 ci-dessus présente un modèle de déploiement permettant de prendre en charge un déploiement de production complet de votre application dans votre VPC. Ce modèle s'appuie sur des zones de disponibilité doubles avec une mise en miroir de basculement synchrone entre les zones de disponibilité, ainsi que sur des serveurs Web à charge équilibrée et des serveurs d'applications associés en tant que clients ECP. Chaque niveau est isolé dans un groupe de sécurité distinct pour les contrôles de sécurité du réseau. Les adresses IP et les plages de ports ne sont ouvertes que selon les besoins de votre application.

Ressources de stockage et de calcul

Stockage

Plusieurs types d'options de stockage sont disponibles. Aux fins de cette architecture de référence, les volumes Amazon Elastic Block Store (Amazon EBS) et Amazon EC2 Instance Store (également appelés drives éphémères) sont examinés pour plusieurs cas d'utilisation possibles. Des détails supplémentaires sur les différentes options de stockage peuvent être trouvés ici et ici.

Elastic Block Storage (EBS)

EBS fournit un stockage durable au niveau des blocs à utiliser avec les instances Amazon EC2 (machines virtuelles) qui peuvent être formatées et montées comme des systèmes de fichiers traditionnels sous Linux ou Windows. Plus important encore, les volumes constituent un stockage hors instance qui persiste indépendamment de la durée de vie d'une seule instance Amazon EC2, ce qui est important pour les systèmes de base de données.

En outre, Amazon EBS offre la possibilité de créer des instantanés ponctuels des volumes, qui sont conservés dans Amazon S3. Ces instantanés peuvent être utilisés comme point de départ pour de nouveaux volumes Amazon EBS, et pour protéger les données pour une durabilité à long terme. Le même instantané peut être utilisé pour instancier autant de volumes que vous le souhaitez. Ces instantanés peuvent être copiés entre les régions AWS, ce qui facilite l'exploitation de plusieurs régions AWS pour l'expansion géographique, la migration des centres de données et la reprise après sinistre. Les tailles des volumes Amazon EBS vont de 1 Go à 16 To, et sont alloués par incréments de 1 Go.

Au sein d'Amazon EBS, il existe trois types différents : Volumes magnétiques, Usage général (SSD) et IOPS provisionnés (SSD). Les sous-sections suivantes fournissent une brève description de chaque type.

Volumes magnétiques

Les volumes magnétiques offrent un stockage rentable pour les applications dont les exigences d'I/O sont modérées ou en rafale. Les volumes magnétiques sont conçus pour fournir une centaine d'opérations d'entrée/sortie par seconde (IOPS) en moyenne, avec une capacité optimale à atteindre des centaines d'IOPS. Les volumes magnétiques sont également bien adaptés à une utilisation en tant que volumes de démarrage, où la capacité d'éclatement permet des temps de démarrage d'instance rapides.

Usage général (SSD)

Les volumes à usage général (SSD) offrent un stockage rentable, idéal pour un large gamme de charges de travail. Ces volumes fournissent des latences inférieures à 10 millisecondes, avec la capacité d'émettre en rafale jusqu'à 3 000 IOPS pendant de longues périodes, et une performance de base de 3 IOPS/Go jusqu'à un maximum de 10 000 IOPS (à 3 334 Go). Levolumes à usage général (SSD) peuvent varier de 1 Go à 16 To.

IOPS provisionnés (SSD)

Les volumes IOPS provisionnés (SSD) sont conçus pour offrir des performances élevées et prévisibles pour les charges de travail à forte intensité d'I/O, telles que les charges de travail de base de données qui sont sensibles aux performances de stockage et à la cohérence du débit d'I/O à accès aléatoire. Vous spécifiez un taux d'IOPS lors de la création d'un volume, et Amazon EBS fournit alors des performances à moins de 10 % de l'IOPS provisionné pendant 99,9 % du temps sur une année donnée. Un volume IOPS provisionné (SSD) peut avoir une taille comprise entre 4 Go et 16 To, et vous pouvez provisionner jusqu'à 20 000 IOPS par volume. Le rapport entre les IOPS provisionnés et la taille du volume demandé peut être de 30 maximum ; par exemple, un volume de 3 000 IOPS doit avoir une taille d'au moins 100 Go. Les volumes provisionnés IOPS (SSD) ont une limite de débit de 256 KB pour chaque IOPS provisionné, jusqu'à un maximum de 320 MB/seconde (à 1 280 IOPS).

Les architectures présentées dans ce document utilisent des volumes EBS, car ils sont mieux adaptés aux charges de travail de production qui nécessitent des opérations d'entrée/sortie par seconde (IOPS) et un débit prévisibles à faible latence. Il faut faire attention lors de la sélection d'un type de VM particulier car tous les types d'instance EC2 ne peuvent pas avoir accès au stockage EBS.

Des détails sur les volumes EBS peuvent être trouvés ici.

Stockage d'instance EC2 (drives éphémères)

Le stockage d'une instance EC2 consiste en un bloc de stockage sur un disque préconfiguré et préattaché sur le même serveur physique qui héberge votre instance Amazon EC2 en fonctionnement. La taille du stockage sur disque fourni varie selon le type d'instance Amazon EC2. Dans les familles d'instances Amazon EC2 qui fournissent le stockage d'instance, les instances plus grandes ont tendance à fournir des volumes de stockage d'instance à la fois plus nombreux et plus importants.

Il existe des familles d'instances Amazon EC2 optimisées pour le stockage (I2) et le stockage dense (D2) qui fournissent ¬un stockage d'instance à usage spécial, destiné à des cas d'utilisation spécifiques. Par exemple, les instances I2 fournissent un stockage d'instance très rapide sauvegardé par SSD, capable de prendre en charge plus de 365 000 IOPS en lecture aléatoire et 315 000 IOPS en écriture, et offrent des modèles de tarification économiquement intéressants.

Contrairement aux volumes EBS, le stockage n'est pas permanent et ne peut être utilisé que pendant la durée de vie de l'instance, et ne peut être détaché ou attaché à une autre instance. Le stockage d'instance est destiné au stockage temporaire d'informations qui changent continuellement. Dans le domaine des technologies et des produits InterSystems; des éléments tels que l'utilisation d'Ensemble ou de Health Connect en tant qu' Enterprise Service Bus (ESB), les serveurs d'applications utilisant le protocole ECP (Enterprise Cache Protocol) ou les serveurs Web avec CSP Gateway seraient d'excellents cas d'utilisation pour ce type de stockage et les types d'instances optimisées pour le stockage, ainsi que l'utilisation d'outils de provisionnement et d'automatisation pour rationaliser leur efficacité et soutenir l'élasticité.

Les détails sur les volumes de l'Instance store sont disponibles ici.

Calcul

Instances EC2

Il existe de nombreux types d'instances disponibles qui sont optimisés pour divers cas d'utilisation. Les types d'instance comprennent des combinaisons variables de CPU, de mémoire, de stockage et de capacités réseau, ce qui permet d'innombrables combinaisons pour adapter les ressources nécessaires à votre application.

Dans le cadre de ce document, les types d'instances Usage Général M4 d'Amazon EC2 seront référencés comme des moyens de dimensionner un environnement. Ces instances offrent des capacités de volume EBS et des optimisations. Des alternatives sont possibles en fonction des besoins en capacité et des modèles de tarification de votre application.

Les instances M4 sont la dernière génération d'instances Usage Général: Cette famille offre un équilibre entre les ressources de calcul, de mémoire et de réseau, et constitue un bon choix pour de nombreuses applications. Les capacités vont de 2 à 64 CPU virtuels et de 8 à 256 Go de mémoire avec une bande passante EBS dédiée correspondante.

En plus des types d'instances individuelles, il existe également des classifications à plusieurs niveaux telles que les Hôtes dédiés, les Instances ponctuelles, les Instances réservées et les Instances dédiées, chacune avec des degrés variables de prix, de performance et d'isolation.

Confirmer la disponibilité et les détails des instances actuellement disponibles ici.

Disponibilité et opérations

Équilibrage de la Charge du serveur Web/App

Des serveurs web externes et internes à charge équilibrée peuvent être nécessaires pour votre application basée sur Caché. Les équilibreurs de charge externes sont utilisés pour l'accès par Internet ou WAN (VPN ou Direct Connect) et les équilibreurs de charge internes sont potentiellement utilisés pour le trafic interne. AWS Elastic Load Balancing fournit deux types d'équilibreurs de charge : l'équilibreur de charge Application load balancer et l'équilibreur de charge Classic Load balancer.

Équilibreur de charge Classic Load Balancer

L'Équilibreur de charge Classic Load Balancer achemine le trafic en fonction des informations au niveau de l'application ou du réseau et est idéal pour un équilibrage de charge simple du trafic sur plusieurs instances EC2 nécessitant une haute disponibilité, une mise à l'échelle automatique et une sécurité robuste. Les détails et caractéristiques spécifiques sont disponibles ici.

Équilibreur de charge Application Load Balancer

Un équilibreur de charge Application Load Balancer est une option d'équilibrage de charge pour le service Elastic Load Balancing qui fonctionne au niveau de la couche applicative et vous permet de définir des règles de routage basées sur le content entre plusieurs services ou conteneurs fonctionnant sur une ou plusieurs instances Amazon EC2. De plus, il existe un support pour WebSockets et HTTP/2. Les détails et caractéristiques spécifiques sont disponibles ici.

Exemple

L'exemple suivant définit un ensemble de trois serveurs web, chacun d'entre eux se trouvant dans une zone de disponibilité distincte afin de fournir les niveaux de disponibilité les plus élevés. Les équilibreurs de charge des serveurs Web doivent être configurés avec Sticky Sessions pour prendre en charge la possibilité d'attribuer les sessions des utilisateurs à des instances EC2 spécifiques à l'aide de cookies. Le trafic sera acheminé vers les mêmes instances à mesure que l'utilisateur continue d'accéder à votre application. 

Le schéma suivant de la Figure-4 présente un exemple simple de l'équilibreur de charge Classic Load Balancer dans AWS.

Figure 4 : Exemple d'équilibreur de charge Classic Load Balancer

Mise en miroir de base de données

Lors du déploiement d'applications basées sur Caché sur AWS, la fourniture d'une haute disponibilité pour le serveur de base de données Caché nécessite l'utilisation d'une mise en miroir synchrone de la base de données afin de fournir une haute disponibilité dans une région AWS primaire donnée et potentiellement d'une mise en miroir asynchrone de la base de données pour répliquer les données vers une mise en veille prolongée dans une région AWS secondaire pour la reprise après sinistre en fonction de vos exigences en matière de contrats de niveau de service de disponibilité.

Un miroir de base de données est un regroupement logique de deux systèmes de base de données, appelés membres de basculement, qui sont des systèmes physiquement indépendants reliés uniquement par un réseau. Après avoir arbitré entre les deux systèmes, le miroir désigne automatiquement l'un d'entre eux comme système primaire ; l'autre membre devient automatiquement le système de sauveguarde. Les postes de travail clients externes ou d'autres ordinateurs se connectent au miroir par l'intermédiaire de l'IP virtuelle (VIP) du miroir, qui est spécifiée lors de la configuration de la mise en miroir. Le miroir VIP est automatiquement lié à une interface sur le système principal du miroir. 

La recommandation actuelle pour le déploiement d'un miroir de base de données dans AWS consiste à configurer trois instances (primaire, de sauvegarde, arbitre) dans le même VPC à travers trois zones de disponibilité différentes. Ainsi, à tout moment, AWS garantit la connectivité externe d'au moins deux de ces VM avec un SLA de 99,95 %. Cela permet une isolation et une redondance adéquates des données de la base de données elle-même. Les détails sur les accords de niveau de service AWS EC2 sont disponibles ici.

Il n'y a pas de limite supérieure rigide sur la latence du réseau entre les membres de basculement. L'impact de l'augmentation de la latence dépend de l'application. Si le temps aller-retour entre les membres de basculement est similaire au temps de service d'écriture au disque, aucun impact n'est attendu. La durée d'aller-retour peut toutefois poser problème lorsque l'application doit attendre que les données deviennent durables (ce que l'on appelle parfois la synchronisation du journal). Les détails de la mise en miroir de la base de données et de la latence du réseau sont disponibles ici.

Adresse IP virtuelle et basculement automatique

La plupart des fournisseurs de cloud IaaS n'ont pas la capacité de fournir une adresse IP virtuelle (VIP) généralement utilisée dans les conceptions de basculement de base de données. Pour y remédier, plusieurs des méthodes de connectivité les plus couramment utilisées, notamment les clients ECP et les passerelles CSP Gateways, ont été améliorées dans Caché, Ensemble et HealthShare afin de ne plus dépendre des capacités VIP, ce qui les rend compatibles avec les miroirs. 

Les méthodes de connectivité telles que xDBC, les sockets TCP/IP directs, ou d'autres protocoles de connexion directe, nécessitent toujours l'utilisation d'un VIP. Pour y remédier, la technologie de mise en miroir des bases de données d'InterSystems permet de fournir un basculement automatique pour ces méthodes de connectivité au sein d'AWS en utilisant des API pour interagir avec un équilibreur de charge élastique (ELB) d'AWS afin d'obtenir une fonctionnalité de type VIP, offrant ainsi une conception de haute disponibilité complète et robuste au sein d'AWS. 

En outre, AWS a récemment introduit un nouveau type d'ELB appelé "Application Load Balancer". Ce type d'équilibreur de charge s'exécute à la Couche 7 et prend en charge le routage basé sur le contenu et les applications qui s'exécutent dans des conteneurs. Le routage basé sur le contenu est particulièrement utile pour les projets de type Big Data qui utilisent un déploiement de données partitionnées ou de partage de données. 

Tout comme avec Virtual IP, il s'agit d'un changement brusque de la configuration du réseau et n'implique aucune logique applicative pour informer les clients existants connectés au membre miroir primaire défaillant qu'un basculement a lieu. Selon la nature de la défaillance, ces connexions peuvent être interrompues à cause de la défaillance elle-même, à cause d'un dépassement de délai ou d'une erreur de l'application, à cause du nouveau primaire qui force l'ancienne instance primaire à s'arrêter, ou à cause de l'expiration du timer TCP utilisé par le client.

Par conséquent, les utilisateurs peuvent être amenés à se reconnecter et à se loguer. Le comportement de votre application déterminerait ce comportement. Des détails sur les différents types d'ELB disponibles sont disponibles ici.

Méthode d'appel d'une instance AWS EC2 vers AWS Elastic Load Balancer

Dans ce modèle, l'ELB peut avoir un pool de serveurs défini avec des membres miroir de basculement et potentiellement des membres miroir asynchrones DR avec une seule des entrées actives qui est le membre miroir primaire actuel, ou seulement un pool de serveurs avec une seule entrée du membre miroir actif. 

Figure 5 : Méthode API pour interagir avec Elastic Load Balancer (interne)

Lorsqu'un membre miroir devient le membre miroir primaire, un appel API est émis depuis votre instance EC2 vers l'AWS ELB pour ajuster/instruire l'ELB du nouveau membre miroir primaire. 

Figure 6 : Basculement vers le membre miroir B à l'aide de l'API pour l'équilibreur de charge

Le même modèle s'applique à la promotion d'un membre miroir asynchrone DR dans le cas où les membres miroirs primaire et de sauveguarde deviennent indisponibles.

Figure-7: Promotion du miroir asynchrone du DR vers le primaire en utilisant l'API vers l'équilibreur de charge

Conformément à la procédure DR standard recommandée, dans la Figure-6 ci-dessus, la promotion du membre DR implique une décision humaine en raison de la possibilité de perte de données due à la réplication asynchrone. Cependant, une fois cette mesure prise, aucune mesure administrative n'est requise sur ELB. Il achemine automatiquement le trafic une fois que l'API est appelée pendant la promotion.

Détails de l'API

Cette API pour appeler la ressource AWS load balancer est définie dans AZMIRROR routine spécifiquement dans le cadre de l'appel de procédure:  

<strong><em>$$CheckBecomePrimaryOK^ZMIRROR()</em></strong>

Dans cette procédure, insérez la logique ou les méthodes API que vous avez choisi d'utiliser à partir d' AWS ELB REST API, de Command Line Interface, etc. Un moyen efficace et sécurisé d'interagir avec ELB est de recourir aux rôles AWS Identity and Access Management (IAM) afin de ne pas avoir à distribuer des informations d'identification à long terme à une instance EC2. Le rôle IAM fournit des autorisations temporaires que Caché peut utiliser pour interagir avec AWS ELB. Des détails sur l'utilisation des rôles IAM attribués à vos instances EC2 sont disponibles ici.

Méthode de sondage de l'équilibreur de charge AWS Elastic Load Balancer

Une méthode de sondage utilisant la page CSP Gateway mirror_status.cxw disponible en 2017.1 peut être utilisée comme méthode de sondage dans le moniteur de santé ELB pour chaque membre miroir ajouté au pool de serveurs ELB. Seul le miroir primaire répondra 'SUCCESS', dirigeant ainsi le trafic réseau uniquement vers le membre primaire actif du miroir. 

Pour être ajoutée à AZMIROIR; cette méthode ne nécessite aucune logique . Veuillez noter que la plupart des dispositifs de réseau d'équilibrage de charge ont une limite sur la fréquence d'exécution de la vérification de l'état. En général, la fréquence la plus élevée n'est pas inférieure à 5 secondes, ce qui est généralement acceptable pour prendre en charge la plupart des accords de niveau de service en matière de disponibilité.

Une requête HTTP pour la ressource suivante testera l'état de membre miroir de la configuration LOCAL Cache.

_ /csp/bin/mirror_status.cxw_

Dans tous les autres cas, le chemin d'accès à ces demandes d'état miroir doit mener au serveur de cache et à l'espace de noms appropriés en utilisant le même mécanisme hiérarchique que celui utilisé pour demander des pages CSP réelles.

Exemple : Pour tester l'état du miroir de la configuration desservant les applications dans le chemin /csp/user/ path:

_ /csp/user/mirror_status.cxw_

Selon que l'instance cible est le membre primaire actif ou non, le Gateway renvoie l'une des réponses CSP suivantes:

**** Succès (Est le membre primaire)**

===============================

   HTTP/1.1 200 OK

   Content-Type: text/plain

   Connection: close

   Content-Length: 7

   SUCCESS

**** Échec (N'est pas le membre primaire)**

===============================

   HTTP/1.1 503 Service Unavailable

   Content-Type: text/plain

   Connection: close

   Content-Length: 6

   FAILED

**** Échec (Le serveur cache ne prend pas en charge la requête Mirror_Status.cxw)**

===============================

   HTTP/1.1 500 Internal Server Error

   Content-Type: text/plain

   Connection: close

   Content-Length: 6

   FAILED

Les figures suivantes présentent les différents scénarios d'utilisation de la méthode de sondage.

Figure 8 : Sondage auprès de tous les membres du miroir

Comme le montre la Figure-8 ci-dessus, tous les membres miroirs sont opérationnels, et seul le membre miroir primaire renvoie "SUCCESS" à l'équilibreur de charge, et donc le trafic réseau sera dirigé uniquement vers ce membre miroir.

Figure 9 : Basculement vers le membre miroir B en utilisant le sondage

Le diagramme suivant illustre la promotion d'un ou plusieurs membres miroir asynchrones DR dans le pool équilibré en charge, ce qui suppose généralement que le même dispositif réseau d'équilibrage de charge dessert tous les membres miroir (les scénarios de répartition géographique sont traités plus loin dans cet article).

Conformément à la procédure DR standard recommandée, la promotion du membre DR implique une décision humaine en raison de la possibilité de perte de données due à la réplication asynchrone. Cependant, une fois cette mesure prise, aucune mesure administrative n'est requise sur ELB. Il découvre automatiquement le nouveau primaire.

Figure-10: Basculement et promotion du membre miroir asynchrone DR à l'aide du sondage

Sauvegarde et Restauration

Plusieurs options sont disponibles pour les opérations de sauvegarde. Les trois options suivantes sont viables pour votre déploiement AWS avec les produits InterSystems. Les deux premières options intègrent une procédure de type instantané qui implique la suspension des écritures de la base de données sur le disque avant la création dde l'instantané, puis la reprise des mises à jour une fois l'instantané réussi. Les étapes de haut niveau suivantes sont suivies pour créer une sauvegarde propre en utilisant l'une ou l'autre des méthodes d'instantané ::

• Pause des écritures dans la base de données via l'appel Freeze API de la base de données.
• Créez des instantanés du système d'exploitation + des disques de données.
• Resume Caché écrit via l'appel de Thaw API base de données.
• Sauvegarde des archives de l'installation vers un emplacement de sauvegarde

Des étapes supplémentaires, telles que les contrôles d'intégrité, peuvent être ajoutées à intervalles réguliers pour garantir une sauvegarde propre et cohérente.

Les points de décision sur l'option à utiliser dépendent des exigences opérationnelles et des politiques de votre organisation. InterSystems est à votre disposition pour discuter plus en détail des différentes options.

Instantanés EBS

Les instantanés EBS sont des moyens très rapides et efficaces de créer un instantané ponctuel sur le stockage Amazon S3 hautement disponible et à moindre coût. Les instantanés EBS ainsi que les capacités InterSystems External Freeze et Thaw API permettent une véritable résilience opérationnelle 24 heures sur 24, 7 jours sur 7, et l'assurance de sauvegardes régulières et propres. Il existe de nombreuses options pour automatiser le processus en utilisant les services fournis par AWS, tels que Amazon CloudWatch Events ou des solutions tierces disponibles sur le marché, telles que Cloud Ranger ou N2W Software Cloud Protection Manager, pour n'en citer que quelques-unes.

En outre, vous pouvez créer par programmation votre propre solution de sauvegarde personnalisée en utilisant les appels API directs par AWS. Des détails sur la façon d'exploiter les API sont disponibles ici et ici.

Instantanés de Logical Volume Manager

Il est également possible d'utiliser de nombreux outils de sauvegarde tiers disponibles sur le marché en déployant des agents de sauvegarde individuels dans le VM lui-même et en exploitant les sauvegardes au niveau des fichiers en conjonction avec les instantanés LVM (Logical Volume Manager) de Linux ou VSS (Volume Shadow Copy Service) de Windows.

L'un des principaux avantages de ce modèle est la possibilité d'effectuer des restaurations au niveau des fichiers des instances basées sur Linux et Windows. Quelques points à noter avec cette solution : étant donné qu'AWS et la plupart des autres fournisseurs de cloud IaaS ne fournissent pas de bandes, tous les référentiels de sauvegarde sont sur disque pour l'archivage à court terme et ont la possibilité d'exploiter le stockage Amazon S3 à faible coût et éventuellement Amazon Glacier pour la rétention à long terme (LTR). Il est fortement recommandé, si vous utilisez cette méthode, d'utiliser un produit de sauvegarde qui supporte les technologies de déduplication afin d'utiliser les référentiels de sauvegarde sur disque de la manière la plus efficace possible.

Quelques exemples de ces produits de sauvegarde avec prise en charge du cloud incluent, sans s'y limiter : Commvault, EMC Networker, HPE Data Protector et Veritas Netbackup. 

Caché Online Backup

Pour les petits déploiements, la fonction intégrée Caché Online Backup est également une option viable. L'utilitaire de sauvegarde en ligne des bases de données d'InterSystems sauvegarde les données dans les fichiers des bases de données en capturant tous les blocs dans les bases de données puis écrit la sortie dans un fichier séquentiel. Ce mécanisme de sauvegarde propriétaire est conçu pour ne causer aucun temps d'arrêt aux utilisateurs du système de production. 

Dans AWS, une fois la sauvegarde en ligne terminée, le fichier de sortie de sauvegarde et tous les autres fichiers utilisés par le système doivent être copiés dans un EC2 agissant comme un partage de fichiers (CIFS/NFS). Ce processus doit être scripté et exécuté dans la machine virtuelle.

La sauvegarde en ligne est l'approche d'entrée de gamme pour les petits sites souhaitant mettre en œuvre une solution de sauvegarde à faible coût. Cependant, à mesure que la taille des bases de données augmente, les sauvegardes externes avec la technologie des instantanés sont recommandées comme meilleure pratique, avec des avantages tels que la sauvegarde des fichiers externes, des temps de restauration plus rapides et une vue des données et des outils de gestion à l'échelle de l'entreprise.

Reprise après sinistre

Lors du déploiement d'une application basée sur Caché sur AWS, il est recommandé que les ressources de secours, notamment le réseau, les serveurs et le stockage, se trouvent dans une région AWS différente ou, au minimum, dans des zones de disponibilité distinctes. La quantité de capacité requise dans la région DR AWS désignée dépend des besoins de votre organisation. Dans la plupart des cas, 100 % de la capacité de production est nécessaire en cas de fonctionnement en mode DR, mais une capacité moindre peut être fournie jusqu'à ce qu'une plus grande quantité soit nécessaire en tant que modèle élastique. Une capacité moindre peut prendre la forme d'un nombre réduit de serveurs Web et d'applications, voire d'un type d'instance EC2 plus petit pour le serveur de base de données. Lors de la promotion, les volumes EBS sont rattachés à un type d'instance EC2 plus important. 

La mise en miroir asynchrone de la base de données est utilisée pour répliquer en continu les instances EC2 de la région DR AWS. La mise en miroir utilise les journaux des transactions de la base de données pour répliquer les mises à jour sur un réseau TCP/IP d'une manière qui a un impact minimal sur les performances du système primaire. Il est fortement recommandé de configurer la compression et le cryptage des fichiers de journal avec ces membres miroirs asynchrones DR.

Tous les clients externes sur l'Internet public qui souhaitent accéder à l'application seront acheminés via Amazon Route53 en tant que service DNS supplémentaire. Amazon Route53 est utilisé comme commutateur pour diriger le trafic vers le centre de données actif actuel. Amazon Route53 remplit trois fonctions principales:

• • Enregistrement de domaine – Amazon Route53 vous permet d'enregistrer des noms de domaine tels que example.com.
• • Service DNS (Domain Name System) – Amazon Route53 traduit les noms de domaines amis comme www.example.com en adresses IP comme 192.0.2.1 Amazon Route53 répond aux requêtes DNS en utilisant un réseau mondial de serveurs DNS faisant autorité, ce qui réduit la latence.
• • Vérification de la santé – Amazon Route53 envoie des requêtes automatisées sur Internet à votre application pour vérifier qu'elle est joignable, disponible et fonctionnelle.

Les détails de ces fonctions sont disponibles ici.

Aux fins de ce document, le basculement DNS et la vérification de l'état de Route53 seront discutés. Les détails de la surveillance de l'état de santé et du basculement DNS sont disponibles ici et ici.

Route53 fonctionne en effectuant des requêtes régulières à chaque point de terminaison, puis en vérifiant la réponse. Si un point de terminaison ne fournit pas de réponse valide. Il n'est plus inclus dans les réponses DNS, qui renverront un autre point d'accès disponible. De cette façon, le trafic des utilisateurs est éloigné des points d'extrémité défaillants et dirigé vers les points d'extrémité disponibles.

En utilisant les méthodes ci-dessus, le trafic ne sera autorisé que vers une région spécifique et un membre miroir spécifique. Ceci est contrôlé par la définition du points d'extrémité qui est une page mirror_status.cxw discutée précédemment dans cet article et présentée à partir du Gateway CSP d'InterSystems. Seul le membre primaire du miroir rapportera "SUCCESS" comme un HTTP 200 de la vérification de santé.

Le diagramme suivant présente à un niveau élevé la stratégie de routage de basculement. Les détails de cette méthode et d'autres sont disponibles ici.

Figure 11 : Stratégie de routine de basculement Amazon Route53

À tout moment, une seule des régions fera un rapport en ligne sur la base de la surveillance des points d'extrémité. Cela garantit que le trafic ne circule que dans une région à la fois. Aucune étape supplémentaire n'est nécessaire pour le basculement entre les régions puisque la surveillance des points de terminaison détectera que l'application dans la région AWS primaire désignée est hors service et que l'application est maintenant en ligne dans la région AWS secondaire. Cela s'explique par le fait que le membre miroir asynchrone DR a été promu manuellement au rang de primaire, ce qui permet à la passerelle CSP de signaler HTTP 200 au point de contrôle d'Elastic Load Balancer.

Il existe de nombreuses alternatives à la solution décrite ci-dessus, et elles peuvent être personnalisées en fonction des exigences opérationnelles et des accords de niveau de service de votre organisation.

Vérification

Amazon CloudWatch est disponible pour fournir des services de vérification pour toutes vos ressources du cloud AWS et vos applications. Amazon CloudWatch peut être utilisé pour collecter et suivre les métriques, collecter et surveiller les fichiers journaux, définir des alarmes et réagir automatiquement aux changements dans les ressources AWS. Amazon CloudWatch peut contrôler les ressources AWS telles que les instances Amazon EC2 

ainsi que les mesures personnalisées générées par vos applications et services, et tous les fichiers journaux que vos applications génèrent. Vous pouvez utiliser Amazon CloudWatch pour obtenir une visibilité à l'échelle du système sur l'utilisation des ressources, les performances des applications et la santé opérationnelle. Les détails sont disponibles ici.

Provisionnement Automatisé

Il existe aujourd'hui de nombreux outils disponibles sur le marché, notamment Terraform, Cloud Forms, Open Stack et CloudFormation d'Amazon. L'utilisation de ces outils et le couplage avec d'autres outils tels que Chef, Puppet, Ansible et d'autres peuvent fournir une infrastructure complète en tant que code prenant en charge DevOps ou simplement le démarrage de votre application d'une manière complètement automatisée. Les détails d'Amazon CloudFormation sont disponibles ici.

Connectivité Réseau

En fonction des exigences de connectivité de votre application, plusieurs modèles de connectivité sont disponibles, utilisant soit Internet, soit un VPN, soit un lien dédié utilisant Amazon Direct Connect. La méthode à choisir dépend de l'application et des besoins de l'utilisateur. L'utilisation de la bande passante pour chacune des trois méthodes varie, et il est préférable de vérifier avec votre représentant AWS ou Amazon Management Console pour confirmer les options de connectivité disponibles pour une région donnée.

Sécurité

Il convient d'être prudent lorsque l'on décide de déployer une application dans un fournisseur public de cloud IaaS. Les politiques de sécurité standard de votre organisation, ou les nouvelles politiques développées spécifiquement pour le cloud, doivent être suivies pour maintenir la conformité de votre organisation en matière de sécurité. Vous devrez également comprendre la souveraineté des données, qui est pertinente lorsque les données d'une organisation sont stockées en dehors de son pays et sont soumises aux lois du pays dans lequel les données résident. Les déploiements en nuage comportent le risque supplémentaire que les données se trouvent désormais en dehors des centres de données des clients et du contrôle de sécurité physique. L'utilisation d'un cryptage de base de données et de journaux InterSystems pour les données au repos (bases de données et journaux) et les données en vol (communications réseau) avec un cryptage AES et SSL/TLS respectivement est fortement recommandée.

Comme pour toute gestion de clé de cryptage, des procédures appropriées doivent être documentées et suivies conformément aux politiques de votre organisation afin de garantir la sécurité des données et d'empêcher tout accès indésirable aux données ou toute violation de la sécurité.

Amazon fournit une documentation complète et des exemples pour fournir un environnement d'exploitation hautement sécurisé pour vos applications basées sur Caché. Assurez-vous de consulter l'IAM (Identity Access Management) pour les différents sujets de discussion qui sont disponibles ici.

Exemples de diagrammes d'architecture

Le diagramme ci-dessous illustre une installation typique de Caché offrant une haute disponibilité sous la forme d'une mise en miroir des bases de données (basculement synchrone et DR asynchrone), de serveurs d'applications utilisant ECP et de plusieurs serveurs Web à charge équilibrée.

Exemple de TrakCare

Le diagramme suivant illustre un déploiement typique de TrakCare avec plusieurs serveurs Web à charge équilibrée, deux serveurs d'impression comme clients ECP et une configuration miroir de la base de données. L'adresse IP virtuelle est utilisée uniquement pour la connectivité non associée à ECP ou au CSP Gateway. Les clients ECP et le CSP Gateway sont compatibles avec le miroir et ne nécessitent pas de VIP.

Si vous utilisez Direct Connect, il existe plusieurs options, notamment les circuits multiples et l'accès multirégional, qui peuvent être activées pour les scénarios de reprise après sinistre. Il est important de travailler avec le(s) fournisseur(s) de télécommunications pour comprendre les scénarios de haute disponibilité et de reprise après sinistre qu'ils prennent en charge.

L'exemple de diagramme d'architecture de référence ci-dessous inclut la haute disponibilité dans la région active ou principale et la reprise après sinistre dans une autre région AWS si la région AWS principale n'est pas disponible. Également dans cet exemple, les miroirs de base de données contiennent l'espace de noms TrakCare DB, TrakCare Analytics et Integration namespace dans cet ensemble de miroirs unique.

Figure-12 : Diagramme d'Architecture de référence AWS TrakCare - Architecture physique

En outre, le diagramme suivant montre une vue plus logique de l'architecture avec les produits logiciels de haut niveau associés installés et leur finalité fonctionnelle.

Figure-13 : Diagramme d'Architecture de référence AWS TrakCare - Architecture logique

Exemple de HealthShare

Le diagramme suivant présente un déploiement typique de HealthShare avec plusieurs serveurs Web équilibrés en termes de charge, avec plusieurs produits HealthShare, notamment Information Exchange, Patient Index, Personal Community, Health Insight et Health Connect. Chacun de ces produits respectifs comprend une paire de miroirs de base de données pour une haute disponibilité dans plusieurs zones de disponibilité. L'adresse IP virtuelle est utilisée uniquement pour la connectivité non associée à ECP ou au CSP Gateway. Les CSP Gateways utilisées pour les communications de services Web entre les produits HealthShare sont sensibles aux miroirs et ne nécessitent pas de VIP.

L'exemple de diagramme d'architecture de référence ci-dessous inclut la haute disponibilité dans la région active ou principale et la reprise après sinistre dans une autre région AWS si la région principale n'est pas disponible. 

Figure-14: Diagramme d'Architecture de référence AWS HealthShare - Architecture physique

En outre, le diagramme suivant montre une vue plus logique de l'architecture avec les produits logiciels de haut niveau associés installés, les exigences et méthodes de connectivité, et leur finalité fonctionnelle.

Figure-15: Diagramme d'Architecture de référence AWS HealthShare - Architecture logique

Les systèmes de bases de données ont des exigences de sauvegarde très spécifiques qui, dans les déploiements d'entreprise, nécessitent une réflexion et une planification préalables. Pour les systèmes de bases de données, l'objectif opérationnel d'une solution de sauvegarde est de créer une copie des données dans un état équivalent à celui de l'arrêt de l'application en douceur.  Les sauvegardes cohérentes avec les applications répondent à ces exigences et Caché fournit un ensemble d'API qui facilitent l'intégration avec des solutions externes pour atteindre ce niveau de cohérence des sauvegardes.

Ces API sont ExternalFreeze et ExternalThaw. ExternalFreeze met temporairement en pause les écritures sur le disque et pendant cette période, Caché commet les changements en mémoire. Pendant cette période, l'opération de sauvegarde doit se terminer et être suivie d'un appel à ExternalThaw. Cet appel engage les démons d'écriture à écrire sur le disque la mise à jour du pool tampon global (cache de la base de données) et reprend les opérations normales des démons d'écriture de la base de données Caché. Ce processus est transparent pour les processus utilisateur de Caché.  Les méthodes spécifiques de la classe API sont les suivantes :

##Class(Backup.General).ExternalFreeze()

##Class(Backup.General).ExternalThaw()

Ces API, associées à la nouvelle capacité d'Azure Backup à exécuter un script avant et après l'exécution d'une opération d'instantané, fournissent une solution de sauvegarde complète pour les déploiements de Caché sur Azure. La [capacité de script pré/post d'Azure Backup] (https://azure.microsoft.com/en-us/blog/announcing-application-consistent-backup-for-linux-vms-using-azure-backup) est actuellement disponible uniquement sur les VM Linux.

Conditions préalables

Au niveau le plus élevé, vous devez effectuer trois étapes avant de pouvoir sauvegarder une VM à l'aide d'Azure Backup:

1. Create a Recovery Services vault
2. Install has the latest version of the VM Agent.
3. Check network access to the Azure services from your VM. 

L'espace de stockage Recovery Services gère les objectifs de sauvegarde, les politiques et les éléments à protéger. Vous pouvez créer une voûte de Recovery Services via le portail Azure ou via un script utilisant PowerShell.  Azure Backup nécessite une extension qui s'exécute dans votre VM, est contrôlée par l'agent Linux VM et la dernière version de l'agent est également nécessaire.  L'extension interagit avec les points d'extrémité HTTPS externes d'Azure Storage et de la voûte Recovery Services.  L'accès sécurisé à ces services depuis la VM peut être configuré à l'aide d'un proxy et de règles réseau dans un groupe de sécurité Azure Network Security Group. 

Vous trouverez plus d'informations sur ces étapes dans la section Préparez votre environnement pour sauvegarder les machines virtuelles déployées par Resource Manager.

La Configuration du pré-scripting et post-scripting

La possibilité d'appeler un script avant et après l'opération de sauvegarde est incluse dans la dernière version de l'extension Azure Backup (Microsoft.Azure.RecoveryServices.VMSnapshotLinux). Pour plus d'informations sur l'installation de l'extension, veuillez consulter [la documentation détaillée des fonctionnalités] (https://docs.microsoft.com/en-us/azure/backup/backup-azure-linux-app-consistent).

Par défaut, l'extension inclut des exemples de pré-scripts et post-scripts situés dans votre VM Linux à l'adresse suivante :

/var/lib/waagent/Microsoft.Azure.RecoveryServices.VMSnapshotLinux-1.0.9110.0/main/tempPlugin

Et doit être copié aux emplacements suivants respectivement.

/etc/azure/prescript.sh
/etc/azure/postScript.sh

Vous pouvez également télécharger le modèle de script à partir de GitHub.

Pour Caché, le script prescript.sh où un appel à l'API ExternalFreeze peut être implémenté et le postScript.sh doivent contenir l'implémentation qui exécute ExternalThaw.

Voici un exemple d'implémentation de prescript.sh pour Caché.

#!/bin/bash
# les variables utilisées pour retourner l'état du script
success=0
error=1
warning=2
status=$success
log_path="/etc/preScript.log"#path of log file
printf  "Logs:\n" > $log_path# TODO: Replace <CACHE INSTANCE> with the name of the running instance
csession <CACHE INSTANCE> -U%SYS "##Class(Backup.General).ExternalFreeze()" >> $log_path
status=$?if [ $status -eq 5 ]; then
echo "SYSTEM IS FROZEN"
printf  "SYSTEM IS FROZEN\n" >> $log_pathelif [ $status -eq 3 ]; then
echo "SYSTEM FREEZE FAILED"
printf  "SYSTEM FREEZE FAILED\n" >> $log_path
status=$error
csession <CACHE INSTANCE> -U%SYS "##Class(Backup.General).ExternalThaw()"
fi

exit $status

Voici un exemple d'implémentation de postScript.sh pour Caché.

#!/bin/bash
# les variables utilisées pour retourner l'état du script
success=0
error=1
warning=2
status=$success
log_path="/etc/postScript.log"#path of log file
printf  "Logs:\n" > $log_path# TODO: Replace <CACHE INSTANCE> with the name of the running instance
csession <CACHE INSTANCE> -U%SYS "##class(Backup.General).ExternalThaw()"
status=$?
if [ $status req 5]; then
echo "SYSTEM IS UNFROZEN"
printf  "SYSTEM IS UNFROZEN\n" >> $log_pathelif [ $status -eq 3 ]; then
echo "SYSTEM UNFREEZE FAILED"
printf  "SYSTEM UNFREEZE FAILED\n" >> $log_path
status=$error
fi
exit $status

Exécution d'une sauvegarde

Dans le portail Azure, vous pouvez déclencher la première sauvegarde en naviguant vers le service de restauration. Veuillez considérer que le temps d'instantané de la VM devrait être de quelques secondes indépendamment de la première sauvegarde ou des sauvegardes suivantes. Le transfert de données de la première sauvegarde prendra plus de temps mais le transfert de données commencera après l'exécution du post-script pour dégeler la base de données et ne devrait pas avoir d'impact sur le temps entre le pré-script et le post-script.

Il est fortement recommandé de restaurer régulièrement votre sauvegarde dans un environnement de non-production et [d'effectuer des contrôles d'intégrité de la base de données] (http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_integrity#GCDI_integrity_verify_utility) pour garantir l'efficacité de vos opérations de protection des données.

Pour plus d'informations sur le déclenchement de la sauvegarde et d'autres sujets tels que la planification de la sauvegarde, veuillez consulter Sauvegarde des machines virtuelles Azure dans une voûte Recovery Services.  

InterSystems a corrigé un défaut pouvant entraîner la corruption des bases de données et des fichiers journaux sur les systèmes AIX avec IBM POWER8 ou des processeurs POWER ultérieurs. Ce défaut peut être déclenché uniquement lorsque le chiffrement de la base de données ou du journal est utilisé.

Pour déclencher ce défaut, les conditions suivantes sont requises :

Bonjour à la communauté,
Dans cet article, je vais présenter mon application iris-mlm-explainer

Cette application web se connecte au service SQL d'InterSystems Cloud pour créer, entraîner, valider et prédire des modèles d'apprentissage automatique, faire des Prédictions et afficher un tableau de bord de tous les modèles entraînés avec une explication du fonctionnement d'un modèle d'apprentissage automatique ajusté. Le tableau de bord fournit des graphiques interactifs sur les performances du modèle, les importances des caractéristiques, les contributions des caractéristiques aux prédictions individuelles, les graphiques de dépendance partielle, les valeurs SHAP (interaction), la visualisation des arbres de décision individuels, etc.

Conditions préalables

• Vous devez avoir un compte à SQL d'InterSystems Cloud
• Vous devez avoir <a book="" fr="" getting-started-installing-git="" git-scm.com="" https:="" v2="">Git</a> installé localement.
• Vous devez avoir <a downloads="" https:="" www.python.org="">Python3</a> installé localement.  

Démarrage

Nous allons suivre les étapes suivantes pour créer et afficher le tableau de bord explicatif d'un modèle :

• Etape 1 : Fermeture/git pull du référentiel

• Étape 2 : Connexion au portail de service SQL d'InterSystems Cloud

  • Étape 2.1 : Ajout et gestion de fichiers
  • Étape 2.2 : Importation des fichiers DDL et des fichiers de données
  • Étape 2.3 : Création du modèle
  • Étape 2.4 : Entraînement du modèle
  • Étape 2.5 : Validation du modèle
  • Étape 3 : Activation de l'environnement virtuel Python

• Étape 4 : Exécution de l'application Web pour la prédiction

• Étape 5 : Exploration du tableau de bord explicatif

Etape 1 : Fermeture/git Extraction du référentiel

Commençons donc par la première étape

Créer un dossier et Cloner/utiliser le git pull pour le référentiel dans n'importe quel répertoire local.

git clone https://github.com/mwaseem75/iris-mlm-explainer.git

Étape 2 : Connexion au portail de service SQL d'InterSystems Cloud

Connectez-vous au portail InterSystems Cloud Service Portal

Sélectionner le déploiement en cours

Étape 2.1 : Ajout et gestion des fichiers

Cliquez sur Ajout et gestion de fichiers (Add and Manage Files)

Le référentiel contient les fichiers USA_Housing_tables_DDL.sql(DDL pour créer les tables), USA_Housing_train.csv(données d'entraînement), et USA_Housing_validate.csv(pour la validation) dans le dossier datasets. Sélectionnez le bouton de téléchargement pour ajouter ces fichiers.

Étape 2.2 : Importation des fichiers DDL et des fichiers de données

Cliquez sur Importation de fichiers, puis sur le bouton radio Instruction(s) DDL ou DML, puis sur le bouton suivant.

Cliquez sur le bouton radio Intersystems IRIS et cliquez ensuite sur le bouton suivant

Sélectionnez le fichier USA_Housing_tables_DDL.sql et appuyez sur le bouton d'importation de fichiers.

Cliquez sur le bouton d'importation "Import" dans la boîte de dialogue de confirmation pour créer le tableau.

###

Cliquez sur le bouton des outils de requête SQL (SQL Query tools) pour vérifier que les tableaux sont créés.

###

Importez des fichiers de données

Cliquez sur Importation de fichiers (Import files), puis sur le bouton radio Données CSV (CSV data), et enfin sur le bouton suivant.

Selectionnez le fichier USA_Housing_train.csv et cliquez sur le bouton suivant

###

Sélectionnez le fichier USA_Housing_train.csv dans la liste déroulante, cochez les cases d'importation de lignes en tant que ligne d'en-tête et de noms de champs dans la ligne d'en-tête correspondant aux noms de colonnes dans le tableau sélectionné, puis cliquez sur Importation de fichiers.

cliquer sur "importation" dans la boîte de dialogue de confirmation

Assurez-vous que 4000 lignes sont mises à jour

Procédez de la même manière pour importer le fichier USA_Housing_validate.csv qui contient 1500 enregistrements.

Étape 2.3 : Création du modèle

Cliquez sur les outils IntegratedM et sélectionnez Créer un panneau (Create Panel).

Saisissez USAHousingPriceModel dans le champ de nom du modèle (Model Name), sélectionnez le tableau usa_housing_train et Prix dans la liste déroulante des champs à prédire (Field to predict). Cliquez sur le bouton "Création du modèle" pour créer le modèle.

Étape 2.4 : Entraînement du modèle

sélectionnez le panneau d'entraînement (Train Panel), sélectionnez USAHousingPriceModel dans la liste déroulante du modèle à entraîner et saisissez USAHousingPriceModel_t1 dans le champ du nom du modèle d'entraînement (Train Model Name)

###

Le modèle sera entraîné une fois l'état de fonctionnement (Run Status) achevé

###

Étape 2.5 : Validation du modèle

Sélectionnez le panneau de validation (Validate Panel), sélectionnez USAHousingPriceModel_t1 dans le modèle entraîné pour valider la liste déroulante, sélectionnez usa_houseing_validate dans le tableau pour valider le modèle à partir de la liste déroulante et cliquez sur le bouton de validation du modèle.

###

Cliquez sur affichage des mesures de validation pour visualiser les mesures.

Cliquez sur l'icône graphique pour afficher le graphique Prédiction VS Réalité.

Étape 3 : Activation de l'environnement virtuel Python

Le référentiel contient déjà un dossier d'environnement virtuel python (venv) avec toutes les bibliothèques nécessaires.

Il suffit d'activer l'environnement
Pour Unix ou MacOS :

<span class="hljs-meta">$</span><span class="bash"> <span class="hljs-built_in">source</span> venv/bin/activate</span>

Pour Windows:

venv\scripts\activate

Étape 4 : Définir les paramètres de connexion à InterSystems SQL Cloud

Le référentiel contient le fichier config.py. Il suffit de l'ouvrir et de le paramétrer

Mettez les mêmes valeurs que celles utilisées dans InterSystems SQL Cloud

Étape 4 : Exécution de l'application Web pour la prédiction

Exécutez la commande suivante dans l'environnement virtuel pour démarrer notre application principale

python app.py

###

Pour démarrer l'application, naviguez jusqu'à http://127.0.0.1:5000/

Entrez l'âge de la maison, le nombre de pièces, le nombre de chambres et la population de la région pour obtenir la prédiction

Étape 5 : Exploration du tableau de bord explicatif

Enfin, exécutez la commande suivante dans l'environnement virtuel pour démarrer notre application principale

python expdash.py

Pour démarrer l'application, naviguez jusqu'à http://localhost:8050/

L'application répertorie tous les modèles entraînés ainsi que notre modèle USAHousingPriceModel. Cliquez sur "aller au panneau de bord" ("go to dashboard") pour voir l'explication du modèle.

Importance des fonctionnalités. Quelles sont les fonctionnalités ayant eu l'impact le plus important ?

Mesures quantitatives de la performance des modèles : dans quelle mesure la valeur prédite est-elle proche de la valeur observée ?

Prédiction et Comment chaque fonctionnalité a-t-elle contribué à la prédiction ?

Ajustez les valeurs des fonctionnalités pour modifier la prédiction

Sommaire des SHAPs, Classement des caractéristiques par valeurs de SHAPs

Sommaire des interactions, classement des fonctionnalités par valeur d'interaction de SHAP

Arbres de décision, affichage des arbres de décision individuels dans la forêt aléatoire

Merci

Salut les développeurs,

Nous sommes honorés de vous inviter à la première rencontre Benelux Caché User Group depuis le début du COVID ! Il est dédié au stockage en colonne, aux licences IRIS, au matériel et aux performances, et au Embedded Python !

⏱ Date : 04 mai 2023 de 13h30 à 17h00

📍Lieu: InterSystems BV, Medialaan 32 / 1, B-1800 Vilvoorde, Belgique

Travaillez-vous ou votre équipe travaille-t-elle avec InterSystems IRIS ou Caché ? Ensuite, l'événement de cet après-midi sera intéressant pour acquérir des connaissances supplémentaires et rencontrer des collègues. L'équipe d'InterSystems sera également présente.

L'ordre du jour comprend des sessions du groupe d'utilisateurs et d'InterSystems lui-même, et à la fin de la réunion, InterSystems fournira une collation et une boisson comme d'habitude. La participation au groupe d'utilisateurs et aux réunions est gratuite !

Mise à jour des plates-formes prises en charge par InterSystems, février 2023

Bienvenue à la toute première Mise à jour des Plates-formes prises en charge ! Nous recevons souvent des questions sur les changements récents et à venir dans la liste des plates-formes et des frameworks pris en charge par la plate-forme de données IRIS d'InterSystems. Cette mise à jour vise à partager les changements récents ainsi que nos meilleures connaissances actuelles sur les changements à venir, mais prévoir l'avenir est une affaire délicate et ceci ne doit pas être considéré comme une véritable feuille de route.

Nous prévoyons de publier ce type de mise à jour tous les trois mois environ, puis de procéder à une réévaluation au bout d'un an. Si vous trouvez cette mise à jour utile, faites-le nous savoir ! Nous apprécierions également toute suggestion visant à l'améliorer.

Une fois cela dit, passons à la mise à jour...

Systèmes d'exploitation de production et architectures de CPU pour IRIS

Red Hat Enterprise Linux

Ubuntu

SUSE Linux

Oracle Linux

Microsoft Windows

AIX

Conteneurs

Systèmes d'exploitation et Architectures de CPU pour IRIS Development

MacOS

CentOS

Systèmes d'exploitation de production et architectures de CPU pour Caché et Ensemble

Documentation sur les plates-formes prises en charge par InterSystems

La documentation des Plates-formes prises en charge par InterSystems est la source de la liste définitive des technologies prises en charge.

… et c'est tout, les gars. Encore une fois, s'il y a quelque chose de plus que vous aimeriez savoir, n'hésitez pas à nous le signaler.

InterSystems met périodiquement à jour ses politiques et pratiques en matière de publication de logiciels afin de s'adapter aux besoins des clients.

Nous sommes en train de modifier notre cadence de publication des mises à jour afin d'être plus prévisibles pour les clients et les partenaires, et de modifier quelques autres aspects.

Cet article résume la cadence de publication de nos produits "Data Platforms" (Plateformes de données) et les changements récents qui y ont été apportés, et vous annonce quelques nouvelles mises à jour.

Pourquoi changer ?

• Nos clients acceptent plus rapidement nos nouvelles versions.
• Les problèmes de sécurité sont plus fréquents, notamment dans les bibliothèques de tiers.
• Nos clients demandent des dates de livraison plus prévisibles.

Qu'est-ce qui n'a pas changé ? Rappel de notre cadence de publication des fonctionnalités

InterSystems utilise une cadence de publication de fonctionnalités à deux flux avec InterSystems IRIS depuis 2018 (voir l' annonce originale original announcement). Nous fournissons :

• Livraison continue (CD) des versions—Ces versions permettent d'accéder rapidement aux nouvelles fonctionnalités et sont idéales pour le développement et le déploiement d'applications qui sont continuellement mises à jour et peuvent bénéficier immédiatement des nouvelles fonctionnalités. On l'appelle parfois le "train rapide".
• Les versions de maintenance prolongée (EM)—ces versions sont moins fréquentes que les versions de livraison continue mais elles apportent la stabilité accrue des versions de maintenance. Elles sont idéales pour les grandes applications d'entreprise où la facilité d'obtenir des correctifs dans les versions de maintenance est plus importante que d'obtenir un accès précoce aux nouvelles fonctionnalités. On l'appelle parfois le train lent.

Les versions EM sont faciles à identifier car leur numéro de version est YYYY.1 (par exemple 2022.1 ou 2023.1). Les versions CD auront un numéro de version de la forme YYYY.2, YYYY.3 etc.

Il y a un an, nous avons fait évoluer notre cadence, en ajoutant des kits pour les versions CD et en ajoutant HealthShare Health Connect dans ces trains de versions aux côtés d'InterSystems IRIS et d'InterSystems IRIS for Health. ( Voir la mise à jour février 2022). Quelques restrictions sur les versions CD du train rapide restent en vigueur : il n'y a pas de mises à jour de maintenance ou de sécurité ; il n'y a pas de conversion sur place à partir de Caché ou Ensemble ; et le chemin de mise à jour pour une version CD est limité à la version CD suivante ou à la version EM suivante.

Les versions de fonctionnalités (EM et CD) passent par une phase de prévisualisation au cours de laquelle les clients peuvent télécharger et utiliser les nouvelles versions, afin de se préparer à la sortie de la nouvelle version. Les prévisualisations sont un moment idéal pour fournir des commentaires et des tests afin de s'assurer que votre application fonctionne bien avec la nouvelle version. À partir de la version 2022.2, nous avons commencé à mettre à jour les prévisualisations toutes les deux semaines, toujours le mercredi.

Les réactions à la cadence de publication et à ces mises à jour ont été très positives, et nous avons pu gérer la cadence de publication à deux flux tout en maintenant une très haute qualité.

Mises à jour des plateformes

Les clients adoptent de nouveaux systèmes d'exploitation beaucoup plus rapidement, notamment dans le cloud. Nous avons modifié notre cadence en conséquence. En 2022, nous avons commencé à ajouter la prise en charge de nouveaux systèmes d'exploitation dans les versions de maintenance. La version 2022.1.1 a ajouté la prise en charge d'Ubuntu 22.04 et la version 2022.1.2 celle de RHEL 9. Cette approche signifie que les clients peuvent adopter de nouveaux systèmes d'exploitation beaucoup plus tôt.

Les changements de sécurité sont plus fréquents, en particulier pour les bibliothèques communes fournies avec ces systèmes d'exploitation, comme OpenSSL. Avec notre version 2022.1, nous avons commencé à utiliser les bibliothèques OpenSSL du système d'exploitation, afin que les clients puissent se tenir au courant des mises à jour de sécurité via leur système d'exploitation. Cela signifie également la compilation et l'emballage de kits séparés pour chaque version majeure d'un système d'exploitation Linux. Nous limitons ces kits à deux versions majeures dans chaque version EM. Si nous introduisons une nouvelle prise en charge du système d'exploitation dans une version de maintenance, nous ne supprimerons pas les versions antérieures, de sorte qu'il peut y avoir trois ensembles de kits ; cela est réduit à deux avec la prochaine version EM. Par exemple, la version 2022.1.2 comporte trois ensembles de kits Red Hat (RHEL 7, RHEL 8 et RHEL 9) ; la version 2022.1.3 comportera les mêmes ensembles de kits, mais la version 2023.1.0 ne comportera que les kits RHEL 8 et RHEL 9.

Comme les changements de plateforme s'accélèrent, nous voulons donner aux clients une visibilité sur ce qui se prépare. Nous avons introduit une "mise à jour des plateformes" trimestrielle sous forme de bulletin d'information ; vous pouvez lire le premier numéro sur la communauté des développeurs. Veuillez nous faire part de vos commentaires sur le format, l'horizon temporel, etc.

Maintenance et mises à jour de sécurité

Nous continuons à fournir des mises à jour de maintenance sur InterSystems IRIS pendant deux ans, ainsi que des mises à jour de maintenance sur Caché et Ensemble (voir Version minimale prise en charge). Outre les mises à jour de maintenance, nous fournissons des corrections de sécurité.

Nous faisons référence à la suite de versions qui mettent à jour une version EM, sur tous les produits et plateformes associés, comme un flux. Par exemple, 2021.1.0, 2021.1.1, 2021.1.2 est un flux, tandis que 2022.1.0, 2022.1.1, 2022.1.2 est un autre flux. Cela signifie que nous fournissons des versions de maintenance pour trois flux (l'EM le plus récent et les EM précédents d'InterSystems IRIS, d'InterSystems IRIS for Health et de Health Connect, ainsi que Caché et Ensemble, qui constitue son propre flux).

À partir d'avril 2023, InterSystems fournira des corrections de sécurité pour les versions actuelles et les versions des trois dernières années d'InterSystems IRIS, ainsi que pour la dernière version de maintenance de Caché. Cela signifie que les corrections de sécurité sont fournies pour deux flux supplémentaires au-delà des mises à jour de maintenance (cinq flux au total). Par exemple, en 2024, InterSystems fournira des corrections de sécurité pour les versions InterSystems IRIS 2021.1.x, 2022.1.x, 2023.1.x, ainsi que pour la version 2024.1.x alors en vigueur ; InterSystems fournira également des corrections de sécurité pour Caché 2018.1.x. 

Nous avons récemment amélioré notre politique de traitement des vulnérabilités de sécurité pour tenir compte du volume plus important de problèmes de sécurité que nous constatons, dont la plupart sont de gravité faible ou moyenne (voir Politique de traitement des vulnérabilités de sécurité mise à jour). Nous incluons désormais des mises à jour de sécurité dans chaque version. Les informations sur les problèmes de gravité élevée et critique font l'objet d'un embargo (pour éviter de fournir des informations qui pourraient être utilisées pour exploiter des brèches de sécurité) jusqu'à ce que ces problèmes soient traités dans tous les flux pris en charge - à ce moment-là, nous émettons une alerte de sécurité avec les détails des vulnérabilités qui ont été traitées.

Des versions de maintenance prévisibles

Les clients nous disent qu'ils apprécient de recevoir régulièrement des mises à jour logicielles et qu'ils veulent être en mesure de faire des plans en fonction de la date à laquelle ils peuvent les attendre. Nous sommes en train d'officialiser notre calendrier de publication des mises à jour, comme suit :

Nous avons publié une version de maintenance pour le flux InterSystems IRIS 2022.1 le 18 janvier (voir notre annonce de la version 2022.1.2). Nous prévoyons de publier des versions de maintenance pour le flux InterSystems IRIS 2021.1 et le flux Caché et Ensemble 2018.1 le 28 février.

En 2023, nous prévoyons une version EM (2023.1) et deux versions CD (2023.2 et 2023.3). Une fois que 2023.1.0 est généralement disponible (GA), il devient le flux IRIS d'InterSystems le plus récent, et 2022.1 devient le flux précédent.

Suppression des versions précédentes de la CMR (mais pas de l'ICR)

Parce que nos sorties sont devenues plus fréquentes et que nous publions plus de kits (un par version majeure de Linux OS), le nombre de versions disponibles sur le site de distribution de logiciels du CMR a considérablement augmenté et est devenu déroutant pour certains clients. Nous adoptons une nouvelle pratique consistant à retirer régulièrement les anciennes versions de chaque flux du site de distribution.

• Seule la version la plus récente du CD sera visible - parce que 2022.3 est maintenant généralement disponible, nous retirerons les images 2022.2 à la fin du mois de février.
• Seule la version de maintenance la plus récente par flux sera visible - 2022.1.1 a été supprimée lors de la publication de 2022.1.2. Cela permet d'éviter le problème des clients qui installent par erreur des logiciels présentant des problèmes de sécurité connus.

Les versions précédentes sont disponibles sur demande. Nous suggérons également aux clients qui standardisent une version unique pour de nombreux sites de conserver leur propre copie du kit pour cette version. Pour garantir l'intégrité, tous les kits et conteneurs sont signés ; les fichiers checksum et les fichiers de signature PGP sont téléchargeables sur le site de distribution du CMR.

Nous travaillons de manière différente avec les conteneurs publiés sur l'InterSystems Container Repository (ICR), car les clients utilisent généralement des versions spécifiques dans les pipelines CI/CD. Nous ne supprimerons pas les anciennes images de l'ICR avant qu'elles aient deux ans. Nous recommandons aux clients de maintenir leurs pipelines CI/CD à jour, et la rétroaction que nous recevons est celui qu'ils font.

Engagement envers la réussite du client

Tous les changements décrits dans cet article ont été effectués dans le but d'aider les clients à réussir. Nous sommes à l'écoute des préoccupations de nos clients concernant les problèmes de sécurité, l'adoption de la plate-forme, les mises à jour de maintenance et la cadence des versions, et nous modifions les choses en fonction de ces rétroactions. N'hésitez pas à nous contacter pour nous faire part de vos commentaires et suggestions !

InterSystems a corrigé un problème qui pouvait empêcher InterSystems IRIS® et Caché de tirer parti des pages volumineuses pour la mémoire partagée sous Windows, même si ces produits signalent que des pages volumineuses sont allouées. Cela peut avoir des effets néfastes sur les performances du système.

Le problème résulte d'un changement dans Windows 10 qui nécessite la modification d'InterSystems IRIS® et de Caché. Notez que ce problème affecte également tous les produits InterSystems basés sur InterSystems IRIS® ou Caché. Le problème se produit sur les versions suivantes de Windows :

Nous venons de publier une mise à jour mineure du gestionnaire de packages, qui a été renommé de ZPM à IPM, comme je l'expliquais en novembre.  Il s'agit simplement d'une version de correction de bogue, interprétant correctement les codes de retour ROBOCOPY et corrigeant une régression qui empêchait l'installation de certains packages.

Obtenez-le ici :

https://github.com/intersystems/ipm/releases/tag/v0.5.2

Au fil des ans, je me suis souvent retrouvé dans la nécessité de créer plusieurs messages HL7 à partir d'un seul message entrant. Il s'agit généralement d'une commande ou d'un résultat provenant d'un laboratoire. Chaque fois que j'ai abordé ce problème, j'ai essayé de repartir de zéro en pensant que la tentative précédente aurait pu être mieux faite.

Récemment, le besoin est réapparu et j'ai pu créer une solution dont je n'avais pas honte. Mon principal souci était que je me retrouvais toujours à m'enterrer dans une BPL, ou à utiliser ObjectScript et à tenter de modifier des messages en utilisant la méthode SetValueAt pour la classe de messages HL7.

Problème

Lorsque le Système A traite plusieurs commandes pour un seul patient, le résultat est transmis dans un seul message avec un ORCgrp répété, contenant les segments OBR et OBX. Le Système B ne peut recevoir qu'un seul OBR par message.

Approche

Développez un processus ObjectScript qui divisera un message unique en plusieurs en fonction du nombre de répétitions ORCgrp, et ce, en manipulant uniquement le message HL7 avec un DTL.

Exécution

Le code (partie 1)

Pour commencer, nous avons besoin d'une classe qui étend Ens.BusinessProcess, et qui attend un message HL7 sur demande :

Class Demo.Processes.MessageSplitter Extends Ens.BusinessProcess{
Method OnRequest(pRequest As EnsLib.HL7.Message) As %Status{
  Quit $$$OK
   }
}

L'étape suivante consiste à boucler le message en fonction du nombre de répétitions ORCgrp. Pour cela, 2 choses sont nécessaires :

1. Le nombre de répétitions
2. Une boucle de type For

Pour obtenir le nombre de répétitions, nous pouvons récupérer le compte du message en utilisant le code suivant :

Set ORCCount = pRequest.GetValueAt("PIDgrpgrp(1).ORCgrp(*)")

Cela va définir la variable "ORCCount" en fonction du nombre de répétitions.

En combinant cela avec une boucle type For et une trace pour voir la sortie, cela ressemble à ceci :

Method OnRequest(pRequest As EnsLib.HL7.Message) As %Status{
   Set ORCCount = pRequest.GetValueAt("PIDgrpgrp(1).ORCgrp(*)")
   For i=1:1:ORCCount {
       $$$TRACE("This is loop number: "_i)
   }
   Quit $$$OK
}

En faisant passer un message avec deux répétitions ORCgrp par ce processus à partir d'une production, nous obtenons :

Comme vous pouvez le voir, nous obtenons deux traces.

A partir de là, nous devons être en mesure d'appeler une transformée, et aussi d'indiquer à cette transformée quelle itération de l'ORCgrp elle doit retourner. Pour cela, nous allons utiliser le paramètre "aux", parfois négligé, pour les classes de transformée.

La transformée

La transformée elle-même peut être très simple. Tout ce que nous voulons pour cela est le suivant :

1. Copier l'en-tête MSH tout en rendant le MessageControlID unique à votre message splitté
2. Définir le premier ORCgrp du message cible à l'itération sur laquelle nous sommes depuis la source.
3. Définir la valeur Target SetIDOBR à " 1 ", car elle sera toujours la première dans le message cible.

Pour cela, notre transformée devrait ressembler à ceci :

Mais attendez - où aux. StringValue obtient-il des données ?

Pour le savoir, il faut revenir au code...

Le code (partie 2)

Nous pouvons transmettre une classe à la transformée via le paramètre aux, et pour ce scénario, je vais juste utiliser un conteneur string. Nous allons également envoyer le résultat de la transformation à une cible afin de voir les résultats :

Class Demo.Processes.MessageSplitter Extends Ens.BusinessProcess{

Property TargetConfigName As Ens.DataType.ConfigName;
Parameter SETTINGS = "TargetConfigName";

Method OnRequest(pRequest As EnsLib.HL7.Message) As %Status{

   Set ORCCount = pRequest.GetValueAt("PIDgrpgrp(1).ORCgrp(*)")
    For i=1:1:ORCCount {
        Set contextString = ##class(Ens.StringContainer).%New()
       Set contextString.StringValue = i
       $$$QuitOnError(##Class(Demo.Transformations.R01Split).Transform(pRequest,.SplitR01,.contextString))
        $$$QuitOnError(..SendRequestAsync(..TargetConfigName,SplitR01,0))
    }
   Quit $$$OK
 }
}

Ensuite, dans la production, nous définissons une destination en utilisant la nouvelle option de paramètres que nous avons créée avec la propriété et le paramètre en tête de la classe, et nous verrons quelque chose comme ceci :

Conclusion

Comme je l'ai dit au début de cet article, j'ai toujours l'impression de développer une solution à ce type de problème, et ensuite je regarde en arrière et je pense que cela pourrait être mieux fait. Cette solution ne fait pas exception, mais elle est certainement meilleure que les itérations précédentes.

Pour améliorer cela à court terme, je vais ajouter des commentaires descriptifs à l'ObjectScript. A plus long terme, j'aimerais pouvoir ajouter un paramètre pour la classe de transformation afin qu'elle puisse être contrôlée depuis l'extérieur de l'ObjectScript.

De façon générale, je considère qu'il s'agit d'une approche que j'adopterai pour les prochains développements et que je ne partirai pas complètement de zéro.

(PS - Je suis heureux de partager le code pour cela, mais je ne peux que joindre un pdf à cet article. Cela semble un peu léger pour être quelque chose pour Open Exchange, mais s'il y a un intérêt pour moi de le télécharger là ou ailleurs, s'il vous plaît faites le moi savoir)

Lors de la création d’un PRA (Privileged Routine Application; qui d’ailleurs n’est pas pertinent uniquement pour les routines mais aussi pour les classes/méthodes), il est important de s’assurer d’inclure un new $ROLES, avant d’appeler AddRoles(). Par exemple:

 New $ROLES

set status=$System. Security.AddRoles(« MyPrivilegedRoutineApplication »)

De cette façon, vous vous assurez que les rôles ajoutés (élevés) « s’évaporent » pour l’utilisateur exécutant ce code, une fois que l’utilisateur est hors du champ d’application de cette routine / méthode.

[Merci @Andreas Dieckow d’avoir validé cela]

Je veux faire une requête dans la base de données du Caché pour trouver les messages où un segment HL7 spécifique est égal à une valeur spécifique. Caché dispose-t-il d'une fonction d'interrogation de type "pipe to XML" ou "segment HL7" ?

Suite de tests d’E/S PerfTools #Analytics #Caché #HealthShare #InterSystems IRIS #Open Exchange #TrakCare But Cette paire d’outils (RanRead et RanWrite) est utilisée pour générer des événements de lecture et d’écriture aléatoires dans une base de données (ou une paire de bases de données) afin de tester les opérations d’entrée/sortie par seconde (IOPS). Ils peuvent être utilisés conjointement ou séparément pour tester la capacité matérielle des E/S, valider les IOPS cibles et garantir des temps de réponse disque acceptables. Les résultats recueillis à partir des tests d’E/S varient d’une configuration à l’autre en fonction du sous-système d’E/S. Avant d’exécuter ces tests, assurez-vous que la surveillance correspondante du système d’exploitation et du niveau de stockage est configurée pour capturer les mesures de performances des E/S en vue d’une analyse ultérieure. La méthode suggérée consiste à exécuter l’outil Performance du système fourni avec IRIS. Veuillez noter qu’il s’agit d’une mise à jour d’une version précédente, qui peut être trouvée ici. Installation Téléchargez les outils PerfTools.RanRead.xml et PerfTools.RanWrite.xml depuis GitHub ici. Importez des outils dans l’espace de noms USER. UTILISATEUR> faire $system. OBJ. Load(« /tmp/PerfTools.RanRead.xml »,"ckf ») UTILISATEUR> faire $system. OBJ. Load(« /tmp/PerfTools.RanWrite.xml »,"ckf ») Exécutez la méthode Help pour afficher tous les points d’entrée. Toutes les commandes sont exécutées dans USER. USER> do ##class(PerfTools.RanRead). Aide() • do ##class(PerfTools.RanRead). Setup(Répertoire,DatabaseName,SizeGB,LogLevel) Crée une base de données et un espace de noms portant le même nom. Le niveau logarithmique doit être compris entre 0 et 3, où 0 correspond à « aucun » et 3 à « verbeux ». • do ##class(PerfTools.RanRead). Exécuter(Répertoire,Processus,Dénombrement,Mode) Exécutez le test d’E/S en lecture aléatoire. Le mode est 1 (par défaut) pour le temps en secondes, 2 pour les itérations, en référence au paramètre Count précédent • do ##class(PerfTools.RanRead). Stop() Termine toutes les tâches en arrière-plan. • do ##class(PerfTools.RanRead). Reset() Supprime les statistiques des exécutions précédentes. Ceci est important pour l’exécution entre les tests, sinon les statistiques des exécutions précédentes sont moyennées dans la version actuelle. • do ##class(PerfTools.RanRead). Purger(Répertoire) Supprime l’espace de noms et la base de données du même nom. • do ##class(PerfTools.RanRead). Export(Répertoire) Exporte un résumé de tous les tests de lecture aléatoire dans un fichier texte délimité par des virgules. USER> do ##class(PerfTools.RanWrite). Aide() • do ##class(PerfTools.RanWrite). Setup(Répertoire,NomBase de données) Crée une base de données et un espace de noms portant le même nom. • do ##class(PerfTools.RanWrite). Run(Répertoire,NumProcs,RunTime,HangTime,HangVariationPct,Longueur du nom global,Profondeur globale du nœud,Longueur globale du sous-nœud) Exécutez le test d’E/S en écriture aléatoire. Tous les paramètres autres que le répertoire ont des valeurs par défaut. • do ##class(PerfTools.RanWrite). Stop() Termine toutes les tâches en arrière-plan. • do ##class(PerfTools.RanWrite). Reset() Supprime les statistiques des exécutions précédentes. • do ##class(PerfTools.RanWrite). Purger(Répertoire) Supprime l’espace de noms et la base de données du même nom. • do ##class(PerfTools.RanWrite). Export(Directory) Exporte un résumé de tout l’historique des tests d’écriture aléatoire dans un fichier texte délimité par des virgules. Coup monté Créez une base de données vide (pré-développée) appelée RAN au moins deux fois la taille de la mémoire de l’hôte physique à tester. Assurez-vous que la taille du cache du contrôleur de stockage de la base de données vide est au moins quatre fois supérieure à celle du contrôleur de stockage. La base de données doit être plus grande que la mémoire pour garantir que les lectures ne sont pas mises en cache dans le cache du système de fichiers. Vous pouvez créer manuellement ou utiliser la méthode suivante pour créer automatiquement un espace de noms et une base de données. USER> do ##class(PerfTools.RanRead). Configuration(« /ISC/tests/TMP »,"RAN »,200,1) Répertoire créé /ISC/tests/TMP/ Création d’une base de données de 200 Go dans /ISC/tests/TMP/ Base de données créée dans /ISC/tests/TMP/ Remarque : On peut utiliser la même base de données pour RanRead et RanWrite, ou utiliser des bases séparées si l’intention de tester plusieurs disques à la fois ou à des fins spécifiques. Le code RanRead permet de spécifier la taille de la base de données, mais pas le code RanWrite, il est donc probablement préférable d’utiliser la commande RanRead Setup pour créer des bases de données prédimensionnées souhaitées, même si l’on utilisera la base de données avec RanWrite. Méthodologie Commencez avec un petit nombre de processus et des temps d’exécution de 30 à 60 secondes. Ensuite, augmentez le nombre de processus, par exemple commencez à 10 tâches et augmentez de 10, 20, 40, etc. Continuez à exécuter les tests individuels jusqu’à ce que le temps de réponse soit constamment supérieur à 10 ms ou que les IOPS calculées n’augmentent plus de manière linéaire. L’outil utilise la commande ObjectScript VIEW qui lit les blocs de base de données en mémoire , donc si vous n’obtenez pas les résultats attendus, tous les blocs de base de données sont peut-être déjà en mémoire. À titre indicatif, les temps de réponse suivants pour les lectures aléatoires de base de données de 8 Ko et 64 Ko (non mises en cache) sont généralement acceptables pour les baies entièrement flash : • Moyenne <= 2ms • Ne pas dépasser <= 5ms Courir Pour RanRead, exécutez la méthode Run en augmentant le nombre de processus et en prenant note du temps de réponse au fur et à mesure. Le principal moteur des IOPS pour RanRead est le nombre de processus. USER> do ##class(PerfTools.RanRead). Exécuter(« /ISC/tests/TMP »,5,60) Outil de performance d’E/S à lecture aléatoire InterSystems Processus RanRead 11742 créant 5 processus de travail en arrière-plan. RanReadJob préparé 11768 pour le parent 11742 RanReadJob préparé 11769 pour le parent 11742 RanReadJob préparé 11770 pour le parent 11742 RanReadJob préparé 11771 pour le parent 11742

RanReadJob préparé 11772 pour le parent 11742 Démarrer 5 processus pour le numéro de tâche RanRead 11742 maintenant!
Pour terminer l’exécution : faites ##class(PerfTools.RanRead). Stop() En attente de finir.................. Tâches en arrière-plan de lecture aléatoire terminées pour le parent 11742 Travail RanRead 5 processus de 11742 (62,856814 secondes) Temps de réponse moyen = 1,23 ms IOPS calculé pour la tâche RanRead 11742 = 4065 Le paramètre Mode de la commande Run utilise par défaut le mode 1, qui utilise le paramètre Count (60 dans l’exemple ci-dessus) comme secondes. Si vous définissez Mode sur 2, le paramètre Count est défini sur un nombre d’itérations par processus, donc s’il est défini sur 100 000, chacune des 5 tâches lira 100 000 fois dans la base de données. C’est le mode utilisé à l’origine par ce logiciel, mais les exécutions chronométrées permettent une coordination plus précise avec des outils de surveillance tels que System Performance, qui sont également chronométrés, et l’outil RanWrite . Pour RanWrite, exécutez la méthode Run en diminuant le paramètre Hangtime. Ce paramètre indique le temps d’attente entre les écritures en secondes et constitue le principal moteur d’IOPS pour RanWrite. On peut également augmenter le nombre de processus en tant que moteur pour IOPS. USER> do ##class(PerfTools.RanWrite). Exécuter(« /ISC/tests/TMP »,1,60,.001) Processus RanWrite 11742 créant 1 processus de travail en arrière-plan. Préparé RanWriteJob 12100 pour parent 11742 Démarrer 1 processus pour le numéro de tâche RanWrite 11742 maintenant! Pour terminer l’exécution : faites ##class(PerfTools.RanWrite). Stop() En attente de finir.................. Travaux d’écriture aléatoire en arrière-plan terminés pour le parent 11742 Les processus 1 de la tâche RanWrite 11742 (60 secondes) avaient un temps de réponse moyen = 0,912 ms IOPS calculé pour la tâche RanWrite 11742 = 1096 Les autres paramètres de RanWrite peuvent généralement être laissés à leurs valeurs par défaut en dehors de circonstances inhabituelles. Ces paramètres sont les suivants : - HangVariationPct : variance sur le paramètre hangtime, utilisée pour imiter l’incertitude ; c’est un pourcentage du paramètre précédent

• Longueur globale du nom : RanWrite choisit aléatoirement un nom global, et c’est la longueur de ce nom. Par exemple, s’il est défini sur 6, le Global peut ressembler à Xr6opg- Profondeur du nœud global et Longueur du sous-nœud global : le Global supérieur n’est pas celui qui est rempli. Ce qui est réellement rempli, ce sont des sous-nœuds, donc définir ces valeurs sur 2 et 4 donnerait une commande comme « set ^Xr6opg(« drb7 »,"xt8v ») = [value] ». Le but de ces deux paramètres et de la longueur du nom global est de s’assurer que le même global n’est pas défini encore et encore, ce qui entraînerait un minimum d’événements d’E/S Pour exécuter RanRead et RanWrite ensemble, au lieu de « do », utilisez la commande « job » pour les deux afin de les exécuter en arrière-plan. Résultats Pour obtenir les résultats simples pour chaque exécution enregistrés dans USER dans la table SQL PerfTools.RanRead et PerfTools.RanWrite, utilisez la commande Export pour chaque outil comme suit. Pour exporter le jeu de résultats dans un fichier texte délimité par des virgules (csv), exécutez la commande suivante : USER> do ##class(PerfTools.RanRead). Exporter(« /ISC/tests/TMP/ « ) Exportation du résumé de toutes les statistiques de lecture aléatoire vers /usr/iris/db/zranread/PerfToolsRanRead_20221023-1408.txt Terminé. Analyse Il est recommandé d’utiliser l’outil SystemPerformance intégré pour acquérir une véritable compréhension du système analysé. Les commandes de SystemPerformance doivent être exécutées dans l’espace de noms %SYS. Pour passer à cela, utilisez la commande ZN: UTILISATEUR> ZN « %SYS » Pour trouver des détails sur les goulots d’étranglement dans un système, ou si l’on a besoin de plus de détails sur la façon dont il fonctionne à ses IOPS cibles, il faut créer un profil SystemPerformance avec une acquisition de données à cadence élevée : %SYS> set rc=$$addprofile^SystemPerformance(« 5minhighdef »,"Un échantillonnage d’exécution de 5 minutes toutes les secondes »,1 300) Ensuite, exécutez ce profil (à partir de %SYS) et revenez immédiatement à USER et démarrez RanRead et/ou RanWrite en utilisant « job » plutôt que « do »: %SYS>set runid=$$run^SystemPerformance(« 5minhighdef ») %SYS> ZN « UTILISATEUR » USER> job ##class(PerfTools.RanRead). Exécuter(« /ISC/tests/TMP »,5,60) USER> job ##class(PerfTools.RanWrite). Exécuter(« /ISC/tests/TMP »,1,60,.001) On peut alors attendre la fin du travail SystemPerformance et analyser le fichier html résultant à l’aide d’outils tels que yaspe. Nettoyer Une fois l’exécution terminée des tests, supprimez l’historique en exécutant : %SYS> do ##class(PerfTools. RanRead). Reset() Vérifiez l’application associée sur InterSystems Open Exchange

Nous essayons de trouver la source des messages abandonnés et avons remarqué que nous sommes incapables d'interroger EnsLib.HL7.Message avec des clauses WHERE ou ORDER BY dans notre instruction SQL.

Je sais que EnsLib.HL7.Message est un tableau système, mais existe-t-il un moyen d'ajouter des index supplémentaires à ce tableau pour que la requête s'exécute mieux/plus rapidement sans affecter le système ?

** Révisé le 12 février 2018

Bien que cet article concerne InterSystems IRIS, il s’applique également aux distributions Caché, Ensemble et HealthShare.

Introduction

La mémoire est gérée en pages.  La taille de page par défaut est de 4 Ko sur les systèmes Linux.  Red Hat Enterprise Linux 6, SUSE Linux Enterprise Server 11 et Oracle Linux 6 ont introduit une méthode permettant d’augmenter la taille des pages en 2 Mo ou 1 Go en fonction de la configuration du système, connue sous le nom de HugePages.

Au début, les HugePages devaient être attribuées au démarrage et, si elles ne sont pas gérées ou calculées correctement, elles pourraient entraîner un gaspillage de ressources.  En conséquence, diverses distributions Linux ont introduit Transparent HugePages avec le noyau 2.6.38 activé par défaut.  Il s’agissait d’un moyen d’automatiser la création, la gestion et l’utilisation de HugePages.  Les versions antérieures du noyau peuvent également avoir cette fonctionnalité, mais peuvent ne pas être marquées comme [toujours] et potentiellement définies sur [madvise].

Transparent Huge Pages (THP) est un système de gestion de la mémoire Linux qui réduit la surcharge des recherches TLB (Translation Lookaside Buffer) sur les machines avec de grandes quantités de mémoire en utilisant des pages de mémoire plus grandes.  Cependant, dans les versions Linux actuelles, THP ne peut mapper que l’espace de tas et de pile de processus individuels.

Je suis heureux d'annoncer une étape importante dans le cycle de vie du gestionnaire de packages ObjectScript, ZPM. Le gestionnaire de packages offre aux développeurs la possibilité de regrouper soigneusement le code ObjectScript, les paramètres de configuration du déploiement et les informations de version de manière pratique. Au cours des dernières années, il a considérablement évolué pour devenir une partie intégrante de nombreux workflows de développement.