Introduction

Dans InterSystems IRIS 2024.3 et les versions ultérieures d'IRIS, le composant AutoML est désormais fourni sous forme de package Python distinct, installé après l'installation. Malheureusement, certaines versions récentes des packages Python sur lesquels AutoML s'appuie ont introduit des incompatibilités et peuvent entraîner des échecs lors de l'entraînement des modèles (instruction TRAIN MODEL). Si vous rencontrez une erreur mentionnant « TypeError » et l'argument de mot-clé « fit_params » ou « sklearn_tags », lisez la suite pour une solution rapide.

Cause principale

Dans cet article, nous aborderons les sujets ci-dessous :

• Qu’est-ce que Kubernetes ?
• Principaux composants Kubernetes (K8s)

Qu’est-ce que Kubernetes?

Kubernetes est un framework d'orchestration de conteneurs open source développé par Google. Essentiellement, il contrôle la vitesse des conteneurs et vous aide à gérer des applications composées de plusieurs conteneurs. De plus, il vous permet de les exploiter dans différents environnements, par exemple des machines physiques, des machines virtuelles, des environnements Cloud ou même des environnements de déploiement hybrides.

Je souhaite aborder les problèmes désagréables liés à la lecture d'un texte plat en ASCII, UTF*
excluant explicitement HTML, EBCDIC, et autres encodages.
D'après Wikipediail existe au moins 8 variantes de caractères de contrôle.

• CR+LF est typique de Windows
• LF est typique du monde Linux/UNIX
• CR est le préféré de Mac

Comme vous pouvez le déduire des noms, l'inspiration vient des machines à écrire mécaniques.

Dans IRIS* comme dans Caché ou Ensemble ou ... les classes %Stream* et %File* offrent la même propriété avec la même valeur par défaut.

Qu'est-ce qu'une image Docker?

Dans ce deuxième article sur les principes fondamentaux des conteneurs, nous examinons ce que sont les images de conteneurs.

Une image Docker est simplement une représentation binaire d'un conteneur.

Un conteneur en cours d'exécution ou simplement un conteneur est l'état d'exécution de l'image du conteneur associée.

Pour plus d'information, n'hésitez pas à lire l'article qui explique ce qu'est un conteneur.

InterSystems prend en charge l'utilisation des images InterSystems IRIS Docker qu'il fournit sous Linux uniquement. Plutôt que d'exécuter des conteneurs en tant que processus natifs, comme sur les plateformes Linux, Docker pour Windows crée une VM Linux fonctionnant sous Hyper-V, le virtualiseur Windows, pour héberger les conteneurs. Ces couches supplémentaires ajoutent une complexité qui empêche InterSystems de prendre en charge Docker pour Windows pour le moment.

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
• Flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD
• Pourquoi des conteneurs?
• Infrastructure de conteneurs
• CD utilisant des conteneurs
• CD utilisant ICM
• Architecture des conteneurs

Dans cet article, nous aborderons la construction de votre propre conteneur et son déploiement.

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
• Flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD
• Pourquoi des conteneurs?
• Infrastructure de conteneurs
• CD utilisant des conteneurs
• CD utilisant ICM

Dans cet article, nous allons créer une diffusion continue avec InterSystems Cloud Manager. ICM est une solution de déploiement et de provisionnement en nuage pour les applications basées sur InterSystems IRIS. Il vous permet de définir la configuration de déploiement souhaitée et ICM la provisionne automatiquement. Pour plus d'informations, consultez : First Look : ICM.

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
• Flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD
• Pourquoi des conteneurs?
• Infrastructure de conteneurs
• CD utilisant des conteneurs

Dans le premier article, 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.

Dans le deuxième article, nous avons évoqué le flux de travail GitLab - un processus complet du cycle de vie du logiciel ainsi que Diffusion continue.

Dans le troisième article, nous avons évoqué l'installation et la configuration de GitLab et la connexion de vos environnements à GitLab

Dans le quatrième article, nous avons écrit une configuration de CD.

Dans le cinquième article, nous avons parlé des conteneurs et de la manière dont ils peuvent être utilisés (et pour quelles raisons).

Dans le sixème article nous abordons des principaux composants dont vous aurez besoin pour exécuter un pipeline de diffusion continue avec des conteneurs et de la façon dont ils fonctionnent tous ensemble.

Dans cet article, nous allons créer une configuration de diffusion continue décrite dans les articles précédents.

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
• Flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD
• Pourquoi des conteneurs?
• Infrastructure de conteneurs
• GitLab CI/CD utilisant des conteneurs

Dans le premier article, 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.

Dans le deuxième article, nous avons évoqué le flux de travail GitLab - un processus complet du cycle de vie du logiciel ainsi que Diffusion continue.

Dans le troisième article, nous avons évoqué l'installation et la configuration de GitLab et la connexion de vos environnements à GitLab

Dans le quatrième article, nous avons écrit une configuration de CD.

Dans le cinquième article, nous avons parlé des conteneurs et de la manière dont ils peuvent être utilisés (et pour quelles raisons).

Dans cet article, nous allons discuter des principaux composants dont vous aurez besoin pour exécuter un pipeline de diffusion continue avec des conteneurs et de la façon dont ils fonctionnent tous ensemble.

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
• Flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD
• Pourquoi les conteneurs?
• GitLab CI/CD utilisant des conteneurs

Dans le premier article, 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.

Dans le deuxième article, nous avons évoqué le flux de travail GitLab - un processus complet du cycle de vie du logiciel ainsi que Diffusion continue.

Dans le troisième article,  nous avons évoqué l'installation et la configuration de GitLab et la connexion de vos environnements à GitLab

Dans le quatrième article, nous avons écrit une configuration de CD.

Dans cet article, nous parlerons des conteneurs et de la manière dont ils peuvent être utilisés (et pour quelles raisons).

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.

Salut la communauté

Dans cet article, nous allons apprendre les sujets ci-dessous répertoriés ci-dessous :

1. Qu'est-ce que Docker ?
2. Certains des avantages de Docker
3. Comment fonctionne Docker ?
4. Image Docker
5. Conteneur Docker
6. Dépôt d'images Docker
7. Dépôt d'images Docker d'InterSystems
8. Installation de Docker
9. Commandes de base de Docker
10. Exécution de l'édition communautaire IRIS à l'aide de Docker
11. Interface graphique du bureau Docker

Alors commençons.

1. Qu’est-ce que Docker ?

Salut la communauté,

Dans mon article précédent, nous avons appris les sujets répertoriés ci-dessous :

1. Qu’est-ce que Docker ?
2. Certains des avantages de Docker
3. Comment fonctionne Docker ?
4. Image Docker
5. Conteneur Docker
6. Dépôt d'images Docker
7. Dépôt d'images Docker d'InterSystems
8. Installation de Docker
9. Commandes de base de Docker
10. Exécution de l'édition communautaire IRIS à l'aide de Docker
11. Interface graphique du bureau Docker

Dans cet article, nous aborderons les sujets suivants

1. Utilisation du fichier Docker Compose (un fichier YAML)
2. Utilisation du fichier Docker (utilisé pour créer une image Docker)
3. Utilisation du volume Docker

Alors commençons.

À titre d'exemple d'application en Java fonctionnant avec le dialecte Hibernate pour IRIS, je souhaitais utiliser l'application RealWorld et j'ai trouvé une réalisation pour Quarkus. L'application RealWorld est un exemple d'application proche d'une application réelle, avec des tests déjà préparés pour le backend. La plupart des exemples de réalisations sont à retrouver ici

L'exemple d'application RealWorld est souvent appelé « Wikipédia pour la création d'applications full-stack ». Il sert de prototype standardisé que les développeurs peuvent utiliser pour créer des applications à l'aide de divers langages et frameworks de programmation. L'application fournit un cas d'utilisation réel en imitant une plate-forme de blogs, avec des fonctionnalités telles que l'authentification des utilisateurs, la gestion des profils, la publication d'articles et les commentaires. Avec un ensemble complet de spécifications, y compris une documentation d'API backend prête à l'emploi et des conceptions frontend, il permet aux développeurs de voir comment les mêmes exigences fonctionnelles sont mises en œuvre dans différentes piles technologiques. L'exemple RealWorld est largement utilisé comme outil d'apprentissage et comme référence pour comparer diverses technologies.

Quarkus

Quarkus est un framework Java open source natif de Kubernetes, conçu pour GraalVM et HotSpot. Créé dans le but d'améliorer l'environnement cloud natif moderne, il réduit considérablement l'empreinte et le temps de démarrage des applications Java. Quarkus est connu pour sa philosophie « privilégiant le conteneur », permettant aux développeurs de créer des applications légères et performantes en mettant l'accent sur l'architecture des microservices. Cette flexibilité en a fait un choix populaire pour les organisations cherchant à passer à des plates-formes sans serveur ou basées sur le cloud, combinant des modèles de programmation impératifs et réactifs. Qu'il s'agisse d'une application Web traditionnelle ou d'un système complexe de microservices, Quarkus fournit une plate-forme robuste pour créer des logiciels évolutifs et maintenables.

Lorsque IRIS 2023.2 atteindra la disponibilité générale, nous apporterons quelques améliorations à la façon dont nous étiquetons et distribuons les conteneurs IRIS et IRIS for Health.

Les conteneurs IRIS ont été étiquetés en utilisant le format du numéro de build complet, par exemple 2023.1.0.235.1. Les clients ont demandé des balises plus stables, afin qu'ils n'aient pas besoin de modifier leurs fichiers dockerfiles/Kubernetes à chaque nouvelle version. Dans cet esprit, nous apportons les modifications suivantes à la façon dont nous étiquetons les images de conteneurs.

Si vous déployez dans plus d'un environnement/région/cloud/client, vous rencontrerez inévitablement le problème de la gestion de la configuration.

Alors que tous vos déploiements (ou juste certains) peuvent partager le même code source, certaines parties, telles que la configuration (paramètres, mots de passe) diffèrent d'un déploiement à l'autre et doivent être gérées différemment.

Dans cet article, j'essaierai d'offrir quelques conseils à ce sujet. Cet article traite principalement des déploiements de conteneurs.

Unification de la base de code

Avant d'aborder la gestion de la configuration, parlons de l'unification des bases de code. Le problème est le suivant : la base de code doit généralement viser à coalescer en une seule version. Bien sûr, à tout moment, vous aurez plusieurs versions de votre base de code - la version DEV avec de toutes nouvelles fonctionnalités, la version TEST avec du code de test supplémentaire, la version PROD, et ainsi de suite. Et c'est fine parce que, dans cet exemple, les changements se regroupent en une seule version au fil du temps. Plusieurs branches DEV deviennent une branche TEST et ainsi de suite.

Le problème commence lorsque nous avons plusieurs versions à l'étape finale de notre pipeline de déploiement. Par exemple, le client ABC a demandé une fonctionnalité particulière XYZ, et il existe maintenant deux versions de la base de code PROD - avec la fonctionnalité XYZ et sans elle. Cette situation est problématique car elle double immédiatement nos délais de construction et notre consommation de ressources. Bien sûr, il n'y a parfois aucun moyen d'y remédier. Cependant, supposons que vous ayez de telles divergences persistantes entre les bases de code. Dans ce cas, il peut être intéressant de rechercher si vous pouvez les regrouper en une seule version - dans ce scénario, la fonctionnalité XYZ est activée ou non au démarrage.

Cela dit, passons à la gestion de la configuration.

Gestion de la configuration

Qu'est-ce que nous voulons ?

 * Ne pas stocker toutes les configurations possibles dans un seul conteneur ( pour une part, ce n'est pas sûr, et pour une autre part, nous avons toujours besoin de choisir la configuration à appliquer).
 * Ne pas construire un conteneur pour chaque configuration (simplifie le pipeline CD)

Nous devons transmettre la configuration (paramètres, secrets, ...) lors du démarrage d'InterSystems IRIS et l'appliquer à notre application.

Transmission de la configuration

Il existe plusieurs façons de transmettre la configuration au démarrage.

Les variables d'environnement

Simple et rapide. Dans le cas où vous souhaitez tout stocker dans une seule variable, utilisez JSON pour la sérialisation. N'oubliez pas par ailleurs que Windows a une limite de 32K caractères pour les variables d'environnement (mégaoctets sous Linux). Pour récupérer une variable d'environnement, utilisez $SYSTEM.Util.GetEnviron("ENV_VAR\NAME"). Le principal avantage est la facilité de mise en œuvre. Vérifiez également votre outil CD - il a généralement un minimum de support des variables d'environnement pendant l'exécution du pipeline, parfois avec un support des secrets pour plus de sécurité.

Les fichiers de montage

La configuration peut être un fichier de montage au démarrage. L'avantage est qu'il n'y a pas de limite de longueur. L'inconvénient est que toutes les offres en nuage ne prennent pas en charge les fichiers de montage, et même si c'est le cas, la gestion des fichiers peut s'avérer plus délicate que celle des variables d'environnement. Sachez que les fichiers peuvent toujours être récupérés à partir des anciennes couches d'un conteneur, même s'ils ont été supprimés à une couche ultérieure.

Fusion du CPF

Les paramètres du système peuvent être transmis via le Fichier de fusion de configuration. Ainsi que ses fonctionnalités intégrées. Inconvénient : Le fichier de fusion CPF ne traite pas les paramètres au niveau de l'application.

Les secrets de Docker/CSP

Docker peut monter un secret sous une forme de fichier à l'intérieur d'un conteneur. Les offres en nuage proposent souvent une fonctionnalité similaire. Utilisez-la à la place des fichiers ordinaires pour améliorer la sécurité.

Traitement de la configuration

Bien, vous avez passé la configuration à l'intérieur d'un conteneur. Que faire maintenant ?

%ZSTART

%ZSTART est votre code personnalisé, exécuté au démarrage du système. Il ressemble à ceci :

SYSTEM
    try {
        new $namespace
        set $namespace = "USER"
        // apply configuration
        set $namespace = "%SYS"
    } catch ex {
        zn "%SYS"
        do ex.Log()
    }
    quit 1

Il est essentiel de noter que %ZSTART doit être testé complètement - car InterSystems IRIS ne démarrera pas (ou se comportera de manière erratique) si la routine %ZSTART renvoie une erreur.

Vous êtes maintenant prêt à appliquer vos paramètres.

La manière dont vous stockez/appliquez les paramètres au niveau de l'application dépend naturellement de l'application, mais les paramètres par défaut du systèmeSystem Default Settings{.editor-rtfLink} sont disponibles si vous utilisez l'interopérabilité. Même si vous n'utilisez pas de productions interopérables, vous pouvez toujours utiliser les paramètres par défaut du système car ils sont disponibles pour tout le monde (tant que l'interopérabilité est activée dans un espace de noms).

Pour créer un nouveau paramètre, exécutez :

Set setting = ##class(Ens.Config.DefaultSettings).%New()
Set setting.ProductionName = production
Set setting.ItemName = itemname
Set setting.HostClassName = hostclassname
Set setting.SettingName = settingname
Set setting.SettingValue = settingvalue
Set setting.Description = description
Set sc = setting.%Save()

Et pour récupérer les paramètres, appelez :

set sc = ##class(Ens.Config.DefaultSettings).%GetSetting(production, itemname, hostclassname, "", settingname, .settingvalue)
set settingvalue = ##class(Ens.Director).GetProductionSettingValue(production, settingname, .sc)

Les hôtes d'interopérabilité reçoivent leurs paramètres automatiquement au démarrage du travail de l'hôte commercial.

Summary

Making your application configurable when deploying to more than one server is essential. It can be pretty easy at the early part of the development cycle, but the costs rise with each hardcoded URL. InterSystems IRIS offers several tools you can use to configure the state of your application at startup.

How do you manage multiple deployments?

Le code source de l'article est disponible à l'adresse suivante : https://github.com/antonum/ha-iris-k8s 

Dans l'article précédent, nous avons expliqué comment configurer IRIS sur un cluster k8s avec une haute disponibilité, basée sur le stockage distribué, au lieu de la mise en miroir traditionnelle. À titre d'exemple, cet article utilisait le cluster Azure AKS. Dans cet article, nous poursuivons l'exploration des configurations de haute disponibilité sur k8s. Cette fois, basée sur Amazon EKS (service Kubernetes géré par AWS) et incluant une option pour effectuer la sauvegarde et la restauration de la base de données, basée sur Kubernetes Snapshot.

Installation

Passons tout de suite au travail. Tout d'abord, vous devez disposer d'un compte AWS et des outils AWS CLI,kubectl et eksctl. Pour créer le nouveau cluster, exécutez la commande suivante :

eksctl create cluster \
--name my-cluster \
--node-type m5.2xlarge \
--nodes 3 \
--node-volume-size 500 \
--region us-east-1

Cette commande prend ~15 minutes, elle déploie le cluster EKS et en fait un cluster par défaut pour votre outil kubectl. Vous pouvez vérifier le déploiement en exécutant :

kubectl obtenir les noeuds
NOM                                              ÉTAT    RÔLES            AGE   VERSION
ip-192-168-19-7.ca-central-1.compute.internal    Prêt    <néant>   18d   v1.18.9-eks-d1db3c
ip-192-168-37-96.ca-central-1.compute.internal   Prêt    <néant>   18d   v1.18.9-eks-d1db3c
ip-192-168-76-18.ca-central-1.compute.internal   Prêt    <néant>   18d   v1.18.9-eks-d1db3c

L'étape suivante consiste à installer le moteur de stockage distribué Longhorn.

kubectl créer l'espace de nom longhorn-system
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.0/deploy/iscsi/longhorn-iscsi-installation.yaml --namespace longhorn-system
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml --namespace longhorn-system

Et enfin, l'IRIS lui-même :

kubectl apply -f https://github.com/antonum/ha-iris-k8s/raw/main/tldr.yaml

À ce stade, vous aurez un cluster EKS entièrement fonctionnel avec le stockage distribué Longhorn et le déploiement IRIS installé. Vous pouvez revenir à l'article précédent et tenter de causer toutes sortes de dommages au cluster et au déploiement d'IRIS, juste pour voir comment le système se répare de lui-même. Consultez la section Simuler la défaillance section.

Bonus n° 1 IRIS en ARM

IRIS EKS et Longhorn sont tous deux compatibles avec l'architecture ARM. Nous pouvons donc déployer la même configuration en utilisant les instances AWS Graviton 2, basées sur l'architecture ARM.

Il suffit de changer le type d'instance pour les nœuds EKS en famille 'm6g' et l'image IRIS en ARM.

eksctl créer cluster \
--name my-cluster-arm \
--node-type m6g.2xlarge \
--nodes 3 \
--node-volume-size 500 \
--region us-east-1

tldr.yaml

conteneurs:
#- image: store/intersystems/iris-community:2020.4.0.524.0
- image: store/intersystems/irishealth-community-arm64:2020.4.0.524.0
name: iris

Ou utilisez simplement :

kubectl apply -f https://github.com/antonum/ha-iris-k8s/raw/main/tldr-iris4h-arm.yaml

Et voilà ! Vous avez obtenu votre cluster IRIS Kubernetes, fonctionnant sur la plateforme ARM.

Bonus n°2 - Sauvegarde et restauration

Une partie souvent négligée de l'architecture niveau production est la capacité de créer des sauvegardes de votre base de données et de les restaurer rapidement et/ou de les cloner en cas de besoin.

Dans Kubernetes, la façon la plus courante de le faire est d'utiliser des instantanés de volumes persistants (Persistent Volume Snapshots).

Tout d'abord, vous devez installer tous les composants k8s requis :

#Installer CSI Snapshotter et CRDs

kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -n kube-system -f https://github.com/kubernetes-csi/external-snapshotter/raw/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml
kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml

Ensuite, configurez les informations d'identification du seau S3 pour Longhorn (voir instructions détaillées):

#Le godet s3 cible de la sauvegarde Longhorn et les informations d'identification à utiliser par Longhorn pour accéder à ce godet.
#Voir https://longhorn.io/docs/1.1.0/snapshots-and-backups/backup-and-restore/set-backup-target/ pour les instructions d'installation manuelle
longhorn_s3_bucket=longhorn-backup-123xx #le nom du godet doit être unique au niveau global, à moins que vous ne souhaitiez réutiliser des sauvegardes et des informations d'identification existantes.
longhorn_s3_region=us-east-1
longhorn_aws_key=AKIAVHCUNTEXAMPLE
longhorn_aws_secret=g2q2+5DVXk5p3AHIB5m/Tk6U6dXrEXAMPLE

La commande suivante reprend les variables d'environnement de l'étape précédente et les utilise pour configurer la sauvegarde Longhorn.

#configurer la cible de sauvegarde Longhorn et les informations d'identification

cat <<EOF | kubectl apply -f -
apiVersion: longhorn.io/v1beta1
kind: Setting
metadata:
 name: backup-target
 namespace: longhorn-system
value: "s3://$longhorn_s3_bucket@$longhorn_s3_region/" # la cible de sauvegarde ici
---
apiVersion: v1
kind: Secret
metadata:
 name: "aws-secret"
 namespace: "longhorn-system"
 labels:
data:
 # echo -n '<secret>' | base64
 AWS_ACCESS_KEY_ID: $(echo -n $longhorn_aws_key | base64)
 AWS_SECRET_ACCESS_KEY: $(echo -n $longhorn_aws_secret | base64)
---
apiVersion: longhorn.io/v1beta1
 kind: Setting
metadata:
 name: backup-target-credential-secret
 namespace: longhorn-system
value: "aws-secret" # nom secret de la sauvegarde ici
EOF

Cela peut sembler compliqué, mais cela indique en fait à Longhorn d'utiliser un godet S3 spécifique avec les informations d'identification spécifiées pour stocker le contenu des sauvegardes.

Voilà, c'est fait ! Si vous allez maintenant dans l'interface utilisateur de Longhorn, vous pourrez créer des sauvegardes, les restaurer, etc.

Voici un petit rappel sur la façon de se connecter à l'interface utilisateur Longhorn :

kubectl get pods -n longhorn-system
# noter le nom complet du pod pour le pod 'longhorn-ui-...'
kubectl port-forward longhorn-ui-df95bdf85-469sz 9000:8000 -n longhorn-system

Cela permettrait de transférer le trafic vers Longhorn UI sur votre site http://localhost:9000.

Sauvegarde/restauration programmatique

Effectuer une sauvegarde et une restauration via l'interface utilisateur Longhorn peut être une première étape suffisante - mais nous ferons un pas en avant et effectuerons la sauvegarde et la restauration de manière programmatique, en utilisant les API Snapshot de k8s.

Tout d'abord, l'instantané lui-même. iris-volume-snapshot.yaml

apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
  name: iris-longhorn-snapshot
spec:
  volumeSnapshotClassName: longhorn
  source:
    persistentVolumeClaimName: iris-pvc

Cet instantané de volume fait référence au volume source 'iris-pvc' que nous utilisons pour notre déploiement IRIS. Il suffit donc de l'appliquer pour lancer immédiatement le processus de sauvegarde.

C'est une bonne idée d'exécuter la fonction de Gel/Dégel du démon d'écriture d'IRIS avant/après l'instantané.

#Gel du démon d'écriture
echo "Gel du démon d'écriture d'IRIS"
kubectl exec -it -n $namespace $pod_name -- iris session iris -U%SYS "##Class(Backup.General).ExternalFreeze()"
status=$?
if [[ $status -eq 5 ]]; then
 echo "IRIS WD EST CONGELÉ, exécution de la sauvegarde"
 kubectl apply -f backup/iris-volume-snapshot.yaml -n $namespace
elif [[ $status -eq 3 ]]; then
 echo "ÉCHEC DU GEL DE L'IRIS WD"
fi
#Dégel du démon d'écriture
kubectl exec -it -n $namespace $pod_name -- iris session iris -U%SYS "##Class(Backup.General).ExternalThaw()"

Le processus de restauration est assez simple. Il s'agit essentiellement de créer un nouveau PVC et de spécifier l'instantané comme source.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: iris-pvc-restored
spec:
  storageClassName: longhorn
  dataSource:
    name: iris-longhorn-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Il suffit ensuite de créer un nouveau déploiement, basé sur ce PVC. Regardez ce script de test dans un référentiel github qui se déroulerait de manière séquentielle :

• Créer un nouveau déploiement d'IRIS
• Ajouter des données à IRIS
• Geler le démon d'écriture, prendre un instantané, dégeler le démon d'écriture
• Créer un clone du déploiement d'IRIS, basé sur l'instantané.
• Vérifier que toutes les données sont toujours présentes

À ce stade, vous aurez deux déploiements IRIS identiques, l'un étant un clone par sauvegarde de l'autre.

Profitez-vous-en bien !

Le nuage Amazon Web Services (AWS) offre un large éventail de services d'infrastructure, tels que des ressources de calcul, des options de stockage et des réseaux, qui sont fournis comme un service public : à la demande, disponibles en quelques secondes, avec une tarification à l'usage. De nouveaux services peuvent être mis à disposition rapidement, sans dépenses d'investissement initiales. Les entreprises, les start-ups, les petites et moyennes entreprises et les clients du secteur public peuvent ainsi accéder aux éléments de base dont ils ont besoin pour répondre rapidement à l'évolution des exigences commerciales.

Updated: 2-Apr, 2021 

L'aperçu et les détails suivants sont fournis par Amazon et peuvent être consultés à l'adresse suivante

ici.

Aperçu

Infrastructure globale d'AWS

L'infrastructure du cloud AWS est construite autour de régions et de AZ (zones de disponibilité). Une région est un emplacement physique dans le monde où nous avons plusieurs zones de disponibilité. Les zones de disponibilité sont constituées d'un ou plusieurs centres de données distincts, chacun doté d'une alimentation, d'une mise en réseau et d'une connectivité redondantes, hébergés dans des installations séparées. Ces zones de disponibilité vous offrent la possibilité d'exploiter des applications et des bases de données de production qui sont plus hautement disponibles, plus tolérantes aux pannes et plus évolutives qu'il ne serait possible de le faire à partir d'un seul centre de données.

Les détails de l'infrastructure mondiale d'AWS sont disponiblesici.

Sécurité et conformité d'AWS

La sécurité dans le cloud computing ressemble beaucoup à la sécurité de vos centres de données sur site, mais sans les coûts de maintenance des installations et du matériel. Dans le cloud, vous n'avez pas à gérer de serveurs physiques ou de dispositifs de stockage. En revanche, vous utilisez des outils de sécurité logiciels pour surveiller et protéger le flux d'informations entrant et sortant de vos ressources en cloud.

Le cloud AWS permet un modèle de responsabilité partagée. Alors qu'AWS gère la sécurité du cloud, vous êtes responsable de la sécurité dans le cloud. Cela signifie que vous gardez le contrôle de la sécurité que vous choisissez de mettre en œuvre pour protéger votre propre contenu, votre plate-forme, vos applications, vos systèmes et vos réseaux, comme vous le feriez dans un centre de données sur site.

Les détails de la sécurité du cloud AWS peuvent être trouvés ici .

L'infrastructure informatique qu'AWS fournit à ses clients est conçue et gérée conformément aux meilleures pratiques de sécurité et à diverses normes de sécurité informatique.  Vous trouverez une liste complète des programmes d'assurance auxquels AWS se conforme ici .

AWS Cloud Plate-forme

AWS se compose many de services en nuage que vous pouvez utiliser dans des combinaisons adaptées aux besoins de votre entreprise ou de votre organisation. La sous-section suivante présente les principaux services AWS par catégorie qui sont couramment utilisés avec les déploiements d'InterSystems IRIS. Il existe de nombreux autres services disponibles et potentiellement utiles pour votre application spécifique.  N'hésitez pas à les rechercher si nécessaire.

Pour accéder aux services, vous pouvez utiliser l'AWS Management Console, l'interface de ligne de commande ou les kits de développement logiciel SDK (Software Development Kits).

<th>
  Détails
</th>

<td>
  Les détails de l'AWS Management Console sont disponibles ici.
</td>

<td>
  Les détails de l'Interface de ligne de commande AWS sont disponibles ici.
</td>

<td>
  Les détails des kits de développement logiciel SDK (Software Development Kits) sont disponibles ici.
</td>

<td>
  De nombreuses options sont disponibles : Les détails d'Amazon Elastic Cloud Computing (EC2) sont disponibles ici Les détails d'Amazon EC2 Container Service (ECS) sont disponibles ici Les détails d'Amazon EC2 Container Registry (ECR) sont disponibles ici Les détails d'Amazon Auto Scaling sont disponibles ici
</td>

<td>
  De nombreuses options sont disponibles : Les détails d'Amazon Elastic Block Store (EBS) sont disponibles ici Les détails d'Amazon Simple Storage Service (S3) sont disponibles ici Les détails d'Amazon Elastic File System (EFS) sont disponibles ici
</td>

<td>
  De nombreuses options sont disponibles. Les détails d'Amazon Virtual Private Cloud (VPC) sont disponibles ici Les détails d'Amazon Elastic IP Addresses sont disponibles ici Les détails d'Amazon Elastic Network Interfaces sont disponibles ici Les détails d'Amazon Enhanced Networking pour Linux sont disponibles ici Les détails d'Amazon Elastic Load Balancing (ELB) sont disponibles ici Les détails d'Amazon Route 53 sont disponibles ici
</td>

Exemples d'architectures InterSystems IRIS

Dans le cadre de cet article, des exemples de déploiement d'InterSystems IRIS pour AWS sont fournis comme point de départ pour le déploiement de votre application spécifique. Ils peuvent être utilisés comme ligne directrice pour de nombreuses possibilités de déploiement.  Cette architecture de référence démontre des options de déploiement très robustes, allant des plus petits déploiements aux charges de travail massivement évolutives pour les besoins de calcul et de données.  

Les options de haute disponibilité et de reprise après sinistre sont abordées dans ce document, ainsi que d'autres opérations système recommandées.  Il est prévu que ces dernières soient modifiées par l'individu pour soutenir les pratiques standard et les politiques de sécurité de son organisation.

InterSystems est à votre disposition pour toute discussion ou question sur les déploiements d'InterSystems IRIS basés sur AWS pour votre application spécifique.

Architectures de référence exemplaires

Les architectures exemplaires suivantes fournissent plusieurs configurations différentes avec des capacités et des possibilités croissantes. Considérez ces exemples de petit développement / production / production importante / production avec des clusters shards qui montrent la progression depuis une configuration modeste pour les efforts de développement jusqu'à des solutions massivement évolutives avec une haute disponibilité appropriée entre les zones et une reprise après sinistre multirégionale. En outre, un exemple d'architecture utilisant les nouvelles capacités de sharding d'InterSystems IRIS Data Platform pour les charges de travail hybrides avec traitement massivement parallèle des requêtes SQL.

Configuration du petit développement

Dans le présent exemple, une configuration minimale est utilisée pour illustrer un environnement de développement de petite taille capable de prendre en charge jusqu'à 10 développeurs et 100 Go de données.  Il est facile de prendre en charge un plus grand nombre de développeurs et de données stockées en changeant simplement le type d'instance de la machine virtuelle et en augmentant le stockage du ou des volumes EBS, le cas échéant.

Cela permet de soutenir les efforts de développement et de se familiariser avec les fonctionnalités d'IRIS d'InterSystems, ainsi qu'avec la création et l'orchestration de conteneurs Docker, si nécessaire.  La haute disponibilité avec la mise en miroir des bases de données n'est généralement pas utilisée avec une petite configuration, mais elle peut être ajoutée à tout moment si la haute disponibilité est nécessaire.  

Diagramme exemplaire de petite configuration

Le diagramme exemplaire de la Figure 2.1.1-a ci-dessous illustre le tableau des ressources de la Figure 2.1.1-b.  Les passerelles incluses ne sont que des exemples et peuvent être adaptées en fonction des pratiques réseau standard de votre organisation.  

Figure-2.1.1-a: Architecture exemplaire de petits développements

Les ressources suivantes dans le VPC AWS sont provisionnées comme une petite configuration minimale.  Les ressources AWS peuvent être ajoutées ou supprimées le cas échéant.  

Ressources AWS pour petites configurations

Un exemple de ressources AWS de petite configuration (Small Configuration AWS) est fourni ci-dessous dans le tableau suivant.

Une sécurité du réseau appropriée et des règles de pare-feu doivent être envisagées pour empêcher tout accès indésirable au VPC.  Amazon fournit les meilleures pratiques en matière de sécurité réseau pour commencer, qui sont disponibles : ici

https://docs.aws.amazon.com/vpc/index.html#lang/en_us

https://docs.aws.amazon.com/quickstart/latest/vpc/architecture.html#best-practices

Si votre politique de sécurité exige des instances VM réellement internes, vous devrez configurer manuellement un proxy NAT sur votre réseau et une route correspondante pour que les instances internes puissent atteindre l'Internet. Il est important de noter que vous ne pouvez pas vous connecter à une instance VM entièrement interne directement en utilisant SSH. Pour vous connecter à de telles machines internes, vous devez configurer une instance de bastion qui possède une adresse IP externe, puis la traverser par un tunnel. Un hôte bastion peut être provisionné pour fournir le point d'entrée externe dans votre VPC.  

Les détails de l'utilisation des bastion hosts sont disponibles : ici

https://aws.amazon.com/blogs/security/controlling-network-access-to-ec2-instances-using-a-bastion-server/

https://docs.aws.amazon.com/quickstart/latest/linux-bastion/architecture.html

Configuration de production

Dans cet exemple, une configuration plus importante est traîtée comme exemple de configuration de production qui incorpore la capacité de mise en miroir de la base de données InterSystems IRIS pour prendre en charge la haute disponibilité et la reprise après sinistre.

Cette configuration comprend une paire de serveurs de base de données InterSystems IRIS en miroir synchrone répartis entre deux zones de disponibilité dans la région 1 pour un basculement automatique, et un troisième membre miroir asynchrone DR dans la région 2 pour une reprise après sinistre dans le cas peu probable où une région AWS entière serait hors ligne. 

DLes détails d'une région multiple avec la connectivité Multi-VPC sont disponibles ici.

InterSystems Arbiter et le serveur ICM sont déployés dans une troisième zone séparée pour plus de résilience.  L'exemple d'architecture comprend également un ensemble de serveurs Web facultatifs à charge équilibrée pour prendre en charge une application Web.  Ces serveurs Web et la passerelle InterSystems Gateway peuvent être mis à l'échelle indépendamment selon les besoins.

Diagramme exemplaire de la configuration de la production

Le diagramme exemplaire de la Figure 2.2.1-a illustre le tableau des ressources de la Figure 2.2.1-b.  Les passerelles incluses ne sont que des exemples et peuvent être adaptées en fonction des pratiques réseau standard de votre organisation.  

Figure 2.2.1-a : Architecture de production exemplaire avec haute disponibilité et reprise après sinistre

Les ressources suivantes au sein du AWS VPC sont recommandées au minimum pour supporter une charge de travail de production pour une application web.  Les ressources AWS peuvent être ajoutées ou supprimées selon les besoins.

Production Configuration AWS Resources

Un exemple de configuration de production des ressources AWS est fourni dans le tableau suivant.

Configuration de production importante

Dans cet exemple, une configuration massivement évolutive est fournie en étendant la capacité d'InterSystems IRIS pour introduire également des serveurs d'applications utilisant le protocole ECP (Enterprise Cache Protocol) d'InterSystems afin de permettre une évolution horizontale massive des utilisateurs.  Un niveau de disponibilité encore plus élevé est inclus dans cet exemple car les clients ECP préservent les détails de la session même en cas de basculement d'une instance de base de données.  Plusieurs zones de disponibilité AWS sont utilisées avec des serveurs d'application basés sur ECP et des membres miroirs de base de données déployés dans plusieurs régions.  Cette configuration est capable de prendre en charge des dizaines de millions d'accès à la base de données par seconde et plusieurs téraoctets de données.  

Diagramme exemplaire de la configuration de la production

Le schéma exemplaire de la Figure 2.3.1-a illustre le tableau des ressources de la Figure 2.3.1-b.  Les passerelles incluses ne sont que des exemples, et peuvent être ajustées en fonction des pratiques réseau standard de votre organisation.  

Cette configuration comprend une paire de miroirs de basculement, quatre clients ECP ou plus (serveurs d'application) et un ou plusieurs serveurs Web par serveur d'application. Les paires de miroirs de base de données à basculement sont réparties entre deux zones de disponibilité AWS différentes dans la même région pour la protection du domaine de défaillance, avec le serveur InterSystems Arbiter et ICM déployé dans une troisième zone distincte pour une résilience supplémentaire.  

La reprise après sinistre s'étend à une deuxième région AWS et à une ou plusieurs zones de disponibilité, comme dans l'exemple précédent.  Plusieurs régions DR peuvent être utilisées avec plusieurs cibles de membres miroirs DR Async si nécessaire.

Figure 2.3.1-a : Architecture exemplaire de la production importante avec serveurs d'application ECP.

Les ressources suivantes au sein du projet AWS VPC sont recommandées au minimum pour prendre en charge un cluster shard. Les ressources AWS peuvent être ajoutées ou supprimées selon les besoins.  

Ressources AWS pour une configuration de la production importante

Un exemple de la configuration de la production importante des ressources AWS est fourni dans le tableau suivant.

Configuration de la production avec InterSystems IRIS Sharded Cluster

Dans cet exemple, une configuration horizontale pour les charges de travail hybrides avec SQL est fournie en incluant les nouvelles capacités d'InterSystems IRIS Sharded Cluster pour fournir une mise à l'échelle horizontale massive des requêtes et des tables SQL sur plusieurs systèmes.  Les détails d'InterSystems IRIS Sharded Cluster et de ses capacités sont présentés plus en détail dans la section 9 de cet article.

Diagramme de configuration exemplaire de production avec InterSystems IRIS Sharded Cluster

Le diagramme exemplaire de la Figure 2.4.1-a illustre la table des ressources de la Figure 2.4.1-b.  Les passerelles incluses ne sont que des exemples et peuvent être adaptées en fonction des pratiques réseau standard de votre organisation.  

Cette configuration comprend quatre paires de miroirs comme nœuds de données.  Chacune des paires de miroirs de base de données à basculement est répartie entre deux zones de disponibilité AWS différentes dans la même région pour la protection du domaine de défaillance, avec InterSystems Arbiter et le serveur ICM déployés dans une troisième zone distincte pour une résilience supplémentaire. 

Cette configuration permet à toutes les méthodes d'accès à la base de données d'être disponibles à partir de n'importe quel nœud de données du cluster.  Les données des grandes tableaux SQL sont physiquement réparties sur tous les nœuds de données pour permettre une parallélisation massive du traitement des requêtes et du volume de données.  La combinaison de toutes ces fonctionnalités permet de supporter des charges de travail hybrides complexes, telles que des requêtes SQL analytiques à grande échelle et l'ingestion simultanée de nouvelles données, le tout au sein d'une seule plate-forme de données InterSystems IRIS.

Figure 2.4.1-a : Exemple de configuration de production avec un Sharded Cluster à haute disponibilité

Notez que dans le diagramme ci-dessus et dans la colonne "type de ressource" du tableau ci-dessous, le terme "EC2" est un terme AWS représentant une instance de serveur virtuel AWS comme décrit plus en détail dans la section 3.1 de ce document. Il ne représente ni n'implique l'utilisation de "nœuds de calcul" dans l'architecture de cluster décrite au chapitre 9.

Les ressources suivantes au sein du VPC AWS sont recommandées au minimum pour prendre en charge un Sharded Cluster.  Les ressources AWS peuvent être ajoutées ou supprimées si nécessaire.  

Production avec des ressources de Sharded Cluster Configuration AWS/span>

Un exemple de la configuration de la production avec des ressources de Sharded Cluster Configuration AWS est fourni dans le tableau suivant.

Introduction aux Cloud Concepts

Amazon Web Services (AWS) fournit un environnement cloud riche en fonctionnalités pour l'infrastructure en tant que service (IaaS), entièrement capable de prendre en charge tous les produits InterSystems, y compris la prise en charge de DevOps basée sur les conteneurs avec la nouvelle plate-forme de données InterSystems IRIS. Il faut veiller, comme pour toute plateforme ou modèle de déploiement, à prendre en compte tous les aspects d'un environnement tels que les performances, la disponibilité, les opérations système, la haute disponibilité, la reprise après sinistre, les contrôles de sécurité et autres procédures de gestion.  Cet article couvre les trois principaux composants de tous les déploiements de cloud computing : Le calcul, le stockage et la mise en réseau.

Moteurs de calcul (machines virtuelles)

Dans AWS EC2, plusieurs options sont disponibles pour les ressources du moteur de calcul avec de nombreuses spécifications de CPU et de mémoire virtuelles et des options de stockage associées.  Il convient de noter qu'au sein d'AWS EC2, les références au nombre de vCPU dans un type de machine donné équivalent à un vCPU, soit un hyper-thread sur l'hôte physique au niveau de la couche hyperviseur.  

Dans le cadre de ce document, les types d'instance m5* et r5* EC2 seront utilisés et sont les plus largement disponibles dans la plupart des régions de déploiement AWS.  Cependant, l'utilisation d'autres types d'instance spécialisés tels que : x1* avec une très grande mémoire sont d'excellentes options pour les très grands ensembles de données de travail conservant des quantités massives de données en mémoire cache, ou i3* avec un stockage d'instance local NVMe.  Les détails de l'accord de niveau de service (SLA) d'AWS sont disponibles ici.

Stockage sur disque

Le type de stockage le plus directement lié aux produits InterSystems est celui des types de disques persistants, mais le stockage local peut être utilisé pour des niveaux de performance élevés si les restrictions de disponibilité des données sont comprises et prises en compte. Il existe plusieurs autres options telles que S3 (buckets) et Elastic File Store (EFS), mais elles sont plus spécifiques aux exigences d'une application individuelle qu'au fonctionnement de la plate-forme de données IRIS d'InterSystems.  

Comme la plupart des autres fournisseurs de cloud computing, AWS impose des limites à la quantité de stockage persistant qui peut être associée à un moteur de calcul individuel.  Ces limites incluent la taille maximale de chaque disque, le nombre de disques persistants attachés à chaque moteur de calcul, et le nombre d'IOPS par disque persistant avec un plafond global d'IOPS par instance de moteur de calcul.  En outre, des limites d'IOPS sont imposées par Go d'espace disque, de sorte qu'il est parfois nécessaire de provisionner davantage de capacité disque pour atteindre le taux d'IOPS requis.  

Ces limites peuvent se modifier au fil du temps et doivent être confirmées avec AWS, le cas échéant.

Il existe trois types de stockage persistant pour les volumes de disque : EBS gp2 (SSD), EBS st1 (HDD) et EBS io1 (SSD).  Les disques EBS gp2 standard sont plus adaptés aux charges de travail de production qui nécessitent des IOPS prévisibles à faible latence et un débit plus élevé. Les disques Persistent standard constituent une option plus économique pour les charges de travail de type développement, test ou archive hors production.  

Les détails sur les différents types de disques et leurs limitations sont disponibles ici.

Mise en réseau VPC

Le réseau de cloud privé virtuel (VPC) est fortement recommandé pour prendre en charge les divers composants de la plate-forme de données InterSystems IRIS, tout en fournissant les contrôles de sécurité réseau appropriés, les diverses passerelles, le routage, les attributions d'adresses IP internes, l'isolation des interfaces réseau et les contrôles d'accès.  Un exemple de VPC sera détaillé dans les exemples fournis dans ce document. 

Les détails de la mise en réseau VPC et des pare-feu sont disponibles ici.

Aperçu du Cloud privé virtuel (VPC)

Les détails d'AWS VPC sont disponibles ici.

Dans la plupart des grands déploiements en nuage, plusieurs VPC sont provisionnés afin d'isoler les différents types de passerelles des VPC applicatifs et de profiter du peering VPC pour les communications entrantes et sortantes. Il est fortement recommandé de consulter votre administrateur réseau pour obtenir des détails sur les sous-réseaux autorisés et les règles de pare-feu de votre entreprise. Le peering VPC n'est pas abordé dans ce document.

Dans les exemples fournis dans ce document, un seul VPC avec trois sous-réseaux sera utilisé pour fournir une isolation réseau des différents composants pour une latence et une bande passante prévisibles et une isolation de sécurité des différents composants d'InterSystems IRIS.  

Network Gateway and Subnet Definitions

Deux passerelles sont fournies dans l'exemple de ce document pour prendre en charge la connectivité Internet et la connectivité VPN sécurisée.  Chaque accès d'entrée doit être doté de règles de pare-feu et de routage appropriées afin de garantir une sécurité adéquate pour l'application.  Les détails sur la façon d'utiliser les Tableaux VPC Route sont disponibles ici.

Trois sous-réseaux sont utilisés dans les exemples d'architectures fournis, dédiés à l'utilisation de la plate-forme de données IRIS d'InterSystems.  L'utilisation de ces sous-réseaux et interfaces réseau distincts permet une flexibilité dans les contrôles de sécurité et la protection et la surveillance de la bande passante pour chacun des trois composants majeurs ci-dessus.  Les détails de la création d'instances de machines virtuelles avec plusieurs interfaces réseau sont disponibles ici.

Les sous-réseaux inclus dans ces exemples :

5. User Space Network pour les utilisateurs connectés et les requêtes
5. Shard Network pour les communications entre les noeuds shards
5. Réseau miroir pour une haute disponibilité utilisant la réplication synchrone et le basculement automatique des nœuds de données individuels.  

Équilibreurs de charge internes

La plupart des fournisseurs de cloud computing IaaS ne sont pas en mesure de fournir une adresse IP virtuelle (VIP) qui est généralement utilisée dans les conceptions de basculement automatique de base de données. Pour remédier à ce problème, plusieurs des méthodes de connectivité les plus couramment utilisées, en particulier les clients ECP et les passerelles Web, sont améliorées dans InterSystems IRIS afin de ne plus dépendre des capacités VIP, ce qui les rend sensibles aux miroirs et automatiques.  

Connectivity methods such as xDBC, direct TCP/IP sockets, or other direct connect protocols, require the use of a VIP-like address. To support those inbound protocols, InterSystems database mirroring technology makes it possible to provide automatic failover for those connectivity methods within AWS using a health check status page called  <span class="Characteritalic" style="font-style:italic">mirror_status.cxw </span> to interact with the load balancer to achieve VIP-like functionality of the load balancer only directing traffic to the active primary mirror member, thus providing a complete and robust high availability design within AWS.  

Les détails de l'équilibreur de charge Elastic Load Balancer (ELB) d'AWS sont disponibles ici.

Figure 4.2-a : Basculement automatique sans adresse IP virtuelle

Les détails de l'utilisation d'un équilibreur de charge pour fournir une fonctionnalité de type VIP sont disponibles ici.  

Sample VPC Topology

En combinant tous les composants, l'illustration suivante de la Figure 4.3-a présente la disposition d'un VPC avec les caractéristiques suivantes :

• Exploitation de plusieurs zones au sein d'une région pour une haute disponibilité
• Fourniture deux régions pour la reprise après sinistre
• Utilisation de plusieurs sous-réseaux pour la ségrégation du réseau
• Intégration de passerelles distinctes pour la connectivité VPC Peering, Internet et VPN
• Utilisation d'un équilibreur de charge en nuage pour le basculement IP des membres du miroir

Veuillez noter que dans AWS, chaque sous-réseau doit résider entièrement dans une zone de disponibilité et ne peut pas s'étendre sur plusieurs zones.  Ainsi, dans l'exemple ci-dessous, la sécurité du réseau ou les règles de routage doivent être correctement définies.  Plus de détails sur les sous-réseaux AWS VPC sont disponibles ici.

Figure 4.3-a : Exemple de topologie de réseau VPC

Aperçu du stockage persistant

Comme indiqué dans l'introduction, il est recommandé d'utiliser les volumes AWS Elastic Block Store (EBS), et plus particulièrement les types de volumes EBS gp2 ou les plus récents gp3.  Les volumes EBS gp3 sont recommandés en raison des taux d'IOPS en lecture et en écriture plus élevés et de la faible latence requise pour les charges de travail des bases de données transactionnelles et analytiques.  Les disques SSD locaux peuvent être utilisés dans certaines circonstances, mais il faut savoir que les gains de performance des disques SSD locaux s'accompagnent de certains compromis en termes de disponibilité, de durabilité et de flexibilité.  

Les détails de la persistance des données du SSD local sont disponibles ici pour comprendre les événements de quand les données du SSD local sont préservées et quand elles ne le sont pas.

LVM PE Striping

Comme d'autres fournisseurs cloud, AWS impose de nombreuses limites au stockage, tant en termes d'IOPS que de capacité d'espace et de nombre de dispositifs par instance de machine virtuelle.  Consultez la documentation d'AWS pour connaître les limites actuelles, qui peuvent être disponibles ici .

Avec ces limites, le striping LVM devient nécessaire pour maximiser l'IOPS au-delà de celui d'un seul périphérique disque pour une instance de base de données.  Dans les exemples d'instances de machine virtuelle fournis, les dispositions de disque suivantes sont recommandées.  Les limites de performance associées aux disques persistants SSD peuvent être disponibles ici . 

Figure 5.1-a : Exemple d'allocation de groupe de volumes LVM

Les avantages du striping LVM permettent de répartir les charges de travail IO aléatoires sur un plus grand nombre de périphériques de disque et d'hériter des files d'attente de disque.  Vous trouverez ci-dessous un exemple d'utilisation du striping LVM avec Linux pour le groupe de volumes de la base de données.  Cet exemple utilise quatre disques dans une bande PE LVM avec une taille d'étendue physique (PE) de 4 Mo.  Il est également possible d'utiliser des tailles PE plus importantes si nécessaire.

• Étape 1 : Créez des disques persistants standard ou SSD selon vos besoins
• Etape 2 : L'ordonnanceur IO est NOOP pour chacun des disques en utilisant "lsblk -do NAME,SCHED"
• Etape 3 : Identifier les périphériques de disque en utilisant "lsblk -do KNAME,TYPE,SIZE,MODEL"
• Étape 4 : Créer un groupe de volumes avec de nouveaux périphériques de disque
  • vgcreate s 4M <vg name>  <liste de tous les disques qui viennent d'être créés>
  Étape 4 : Créer un groupe de volumes avec de nouveaux périphériques de disque
  • example: <span style="color:#c0392b;"><i>vgcreate -s 4M vg_iris_db /dev/sd[h-k]</i></span>
• Étape 4 : Créer un volume logique
  • lvcreate n <lv name> -L <size of LV> -i <number of disks in volume group> -I 4MB <vg name>
  • example: <i>lvcreate -n lv_irisdb01 -L 1000G -i 4 -I 4M vg_iris_db</i>
• Étape 5 : Créer un système de fichiers
  • mkfs.xfs K <périphérique de volume logique>
  • example: <i>mkfs.xfs -K /dev/vg_iris_db/lv_irisdb01</i>
• Étape 6 : Monter le système de fichiers
  • éditer /etc/fstab avec les entrées de montage suivantes
    • /dev/mapper/vg_iris_db-lv_irisdb01    /vol-iris/db    xfs defaults 0 0
    • mount /vol-iris/db

En utilisant le tableau ci-dessus, chacun des serveurs InterSystems IRIS aura la configuration suivante avec deux disques pour SYS, quatre disques pour DB, deux disques pour les journaux primaires et deux disques pour les journaux alternatifs.

Figure 5.1-b : Configuration InterSystems IRIS LVM

Pour la croissance, LVM permet d'étendre les périphériques et les volumes logiques lorsque cela est nécessaire, sans interruption.  Consultez la documentation de Linux sur les meilleures pratiques pour la gestion continues et l'expansion des volumes LVM.

Provisionnement

La nouveauté avec InterSystems IRIS est InterSystems Cloud Manager (ICM).  ICM exécute de nombreuses tâches et offre de nombreuses options pour le provisionnement d'InterSystems IRIS Data Platform. ICM est fourni sous la forme d'une image Docker qui comprend tous les éléments nécessaires au provisionnement d'une solution robuste basée sur le cloud AWS. 

ICM supporte actuellement le provisionnement sur les plateformes suivantes :

• Amazon Web Services avec GovCloud (AWS / GovCloud)
• Google Cloud Plate-forme (GCP)
• Microsoft Azure Resource Manager, avec l'administration (ARM / MAG)
• VMware vSphere (ESXi)

ICM et Docker peuvent fonctionner à partir d'un poste de travail de bureau ou d'un ordinateur portable, ou encore à partir d'un modeste serveur de "provisionnement" et d'un référentiel centralisé.  

Le rôle d'ICM dans le cycle de vie des applications est le suivant : Définir -> Approvisionner -> Déployer -> Gérer

Les détails de l'installation et de l'utilisation de la GIC avec Docker sont disponibles ici.

Container Monitoring

ICM comprend deux dispositifs de surveillance de base pour les déploiements basés sur des conteneurs: Rancheret Weave Scope.  Ni l'un ni l'autre ne sont déployés par défaut, et doivent être spécifiés dans le fichier defaults à l'aide du champ Monitor.  Les détails de la surveillance, de l'orchestration et de la planification avec ICM sont disponibles ici.

Une présentation de Rancher et une documentation sont disponibles ici.

Une présentation de Weave Scope et une documentation sont disponibles ici.

Haute disponibilité

La mise en miroir des bases de données InterSystems offre le plus haut niveau de disponibilité dans tout environnement en nuage.  AWS n'offre aucune garantie de disponibilité pour une seule instance EC2, la mise en miroir de bases de données est donc un niveau de base de données requis qui peut également être couplé à l'équilibrage de charge et aux groupes d'auto-évaluation.  

Les sections précédentes ont abordé la manière dont un équilibreur de charge en nuage fournira un basculement automatique de l'adresse IP pour une capacité de type IP virtuelle (VIP) avec une mise en miroir de la base de données.  L'équilibreur de charge cloud utilise mirror_status.cxwla page d'état du bilan de santé mentionnée précédemment dans la section Internal Load Balancers. Il existe deux modes de mise en miroir des bases de données : synchrone avec basculement automatique et asynchrone.  Dans cet exemple, la mise en miroir synchrone avec basculement automatique sera couverte.  Les détails de la mise en miroir sont disponibles ici.

La configuration de mise en miroir la plus élémentaire est une paire de membres miroirs à basculement dans une configuration contrôlée par un arbitre.  L'arbitre est placé dans une troisième zone au sein de la même région afin d'éviter que des pannes potentielles de la zone de disponibilité n'affectent à la fois l'arbitre et l'un des membres miroirs.

Il existe de nombreuses façons de configurer le mirroring spécifiquement dans la configuration du réseau.  Dans cet exemple, nous allons utiliser les sous-réseaux définis précédemment dans Network Gateway et Subnet Definitions sections de ce document.  Des exemples de schémas d'adresses IP seront fournis dans une section suivante. Pour les besoins de cette section, seules les interfaces réseau et les sous-réseaux désignés seront représentés.

Figure 7-a : Exemple de configuration miroir avec arbitre

Reprise après sinistre

La mise en miroir des bases de données InterSystems étend la capacité de haute disponibilité pour prendre également en charge la reprise après sinistre vers une autre région géographique AWS afin de soutenir la résilience opérationnelle dans le cas peu probable où une région AWS entière serait mise hors ligne.  La manière dont une application doit supporter de telles pannes dépend de l'objectif de temps de récupération (RTO) et des objectifs de point de récupération (RPO).  Ceux-ci fourniront le cadre initial de l'analyse nécessaire à la conception d'un plan de reprise après sinistre approprié.  Le lien suivant fournit un guide des éléments à prendre en compte lors de l'élaboration d'un plan de reprise après sinistre pour votre application.  https://aws.amazon.com/disaster-recovery/

Mise en miroir asynchrone des bases de données

La mise en miroir des bases de données InterSystems IRIS Data Platform offre des fonctionnalités robustes pour la réplication asynchrone des données entre les zones de disponibilité et les régions AWS afin de soutenir les objectifs RTO et RPO de votre plan de reprise après sinistre.  Les détails des membres de la mise en miroir asynchrone sont disponibles ici.

Comme dans la section précédente sur la haute disponibilité, un équilibreur de charge cloud fournira un basculement automatique d'adresse IP pour une capacité d'IP virtuelle (de type VIP) pour la mise en miroir asynchrone DR également en utilisant la même mirror_status.cxwpage d'état de contrôle de santé mentionnée précédemment dans la section d'Équilibreurs de charge internes. 

Dans cet exemple, la mise en miroir de basculement asynchrone DR sera couverte ainsi que l'introduction du service AWS Route53 DNS pour fournir aux systèmes ascendants et aux postes de travail clients une adresse DNS unique, quelle que soit la zone de disponibilité ou la région dans laquelle votre déploiement InterSystems IRIS fonctionne. 

Les détails de AWS Route53 sont disponibles ici.

Figure 8.1-a: Sample DR Asynchronous Mirroring with AWS Route53

Dans l'exemple ci-dessus, les adresses IP de l'équilibreur de charge Elastic Load Balancer (ELB) des deux régions qui sont en tête des instances InterSystems IRIS sont fournies à Route53, et ce dernier ne dirigera le trafic que vers le membre miroir qui est le miroir primaire actif, quelle que soit la zone de disponibilité ou la région où il se trouve.

Cluster Sharded

IInterSystems IRIS comprend un ensemble complet de fonctionnalités permettant de faire évoluer vos applications, qui peuvent être appliquées seules ou en combinaison, selon la nature de votre charge de travail et les défis de performance spécifiques auxquels elle fait face. L'une d'entre elles, le sharding, répartit les données et leur cache associé sur plusieurs serveurs, ce qui permet de faire évoluer les performances des requêtes et de l'ingestion de données de manière flexible et peu coûteuse, tout en maximisant la valeur de l'infrastructure grâce à une utilisation très efficace des ressources. Un cluster sharded InterSystems IRIS peut offrir des avantages significatifs en termes de performances pour une grande variété d'applications, mais surtout pour celles dont la charge de travail comprend un ou plusieurs des éléments suivants :

• L'ingestion de données à haut volume ou à grande vitesse, ou une combinaison de ces éléments.
• Des ensembles de données relativement importants, des requêtes qui renvoient de grandes quantités de données, ou les deux.
• Les requêtes complexes qui effectuent de grandes quantités de traitement de données, comme celles qui analysent beaucoup de données sur disque ou qui impliquent un travail de calcul important.

Chacun de ces facteurs influence à lui seul le gain potentiel du sharding, mais l'avantage peut être renforcé lorsqu'ils se combinent. Par exemple, la combinaison de ces trois facteurs (grandes quantités de données ingérées rapidement, grands ensembles de données et requêtes complexes qui récupèrent et traitent beaucoup de données) fait de la plupart des charges de travail analytiques actuelles de très bons candidats pour le sharding.

Notez que ces caractéristiques sont toutes liées aux données ; la fonction principale d'InterSystems IRIS sharding est de s'adapter au volume de données. Cependant, un cluster sharded peut également inclure des fonctionnalités qui évoluent en fonction du volume d'utilisateurs, lorsque les charges de travail impliquant certains ou tous ces facteurs liés aux données connaissent également un volume de requêtes très élevé de la part d'un grand nombre d'utilisateurs. Le sharding peut également être combiné à une mise à l'échelle verticale.

Aperçu opérationnel

Au cœur de l'architecture sharded se trouve le partitionnement des données et de leur cache associé sur plusieurs systèmes. Un cluster sharded partitionne physiquement les grandes tableaux de base de données horizontalement - c'est-à-dire par ligne - sur plusieurs instances InterSystems IRIS, appelées nœuds de données, tout en permettant aux applications d'accéder de manière transparente à ces tableaux par le biais de n'importe quel nœud et de continuer à voir l'ensemble des données comme une seule union logique. Cette architecture offre trois avantages :

• Parallel processing

Les requêtes sont exécutées en parallèle sur les nœuds de données, les résultats étant fusionnés, combinés et renvoyés à l'application en tant que résultats complets de la requête par le nœud auquel l'application s'est connectée, ce qui améliore considérablement la vitesse d'exécution dans de nombreux cas.

• Mise en cache partitionnée

Chaque nœud de données dispose de son propre cache, dédié à la partition de données de la table sharded qu'il stocke, plutôt que le cache d'une instance unique desservant l'ensemble des données, ce qui réduit considérablement le risque de déborder du cache et de forcer des lectures sur disque dégradant les performances.

• Chargement parallèle

Les données peuvent être chargées sur les nœuds de données en parallèle, ce qui réduit les conflits de cache et de disque entre la charge de travail d'ingestion et la charge de travail d'interrogation et améliore les performances des deux.

Les détails du cluster sharded InterSystems IRIS sont disponibles ici.

Éléments du sharding et types d'instance

Un cluster sharded se compose d'au moins un nœud de données et, si nécessaire pour des performances spécifiques ou des exigences de charge de travail, d'un nombre optionnel de nœuds de calcul. Ces deux types de nœuds offrent des blocs de construction simples présentant un modèle de mise à l'échelle simple, transparent et efficace.

Data Nodes

Les nœuds de données stockent les données. Au niveau physique, les données du tableau sharded[1]sont réparties sur tous les nœuds de données du cluster et les données du tableau non sharded sont physiquement stockées sur le premier nœud de données uniquement. Cette distinction est transparente pour l'utilisateur, à l'exception peut-être du fait que le premier nœud pourrait avoir une consommation de stockage légèrement plus élevée que les autres, mais cette différence devrait devenir négligeable, car les données du tableau sharded dépassent généralement les données du tableau non sharded d'au moins un ordre de grandeur. 

Les données des tableaux sharded peuvent être rééquilibrées dans le cluster si nécessaire, généralement après l'ajout de nouveaux nœuds de données. Cette opération permet de déplacer des "seaux" de données entre les nœuds afin d'obtenir une distribution plus ou moins égale des données.

Au niveau logique, les données des tableaux non shardés et l'union de toutes les données des tableaux shardés sont visibles depuis n'importe quel nœud, de sorte que les clients verront l'ensemble des données, quel que soit le nœud auquel ils se connectent. Les métadonnées et le code sont également partagés entre tous les nœuds de données.

Le diagramme d'architecture de base d'un cluster sharded se compose simplement de nœuds de données qui apparaissent uniformément dans le cluster. Les applications clientes peuvent se connecter à n'importe quel nœud et percevront les données comme si elles étaient locales.

Figure 9.2.1-a : Diagramme de base d'un cluster sharded

---

[1]Par commodité, le terme “données de tableau sharded” est utilisé dans l'ensemble du document pour représenter les donnée “d'étendue” pour tout modèle de données prenant en charge le sharding qui est marqué comme sharded. Les termes “données de tableau non sharded” et “données non sharded” sont utilisés pour représenter les données qui se trouvent dans une étendue shardable non marquée comme telle ou pour un modèle de données qui ne prend simplement pas encore en charge le sharding.

Nœuds de calcul

Pour les scénarios avancés nécessitant de faibles latences, potentiellement en contradiction avec un afflux constant de données, des nœuds de calcul peuvent être ajoutés afin de fournir une couche de mise en cache transparente pour le traitement des requêtes. 

Les nœuds de calcul stockent les données en cache. Chaque nœud de calcul est associé à un nœud de données pour lequel il met en cache les données du tableau sharded correspondant et, en plus de cela, il met également en cache les données du tableau non sharded si nécessaire, pour satisfaire les requêtes. 

Figure 9.2.2-a : Cluster shared avec nœuds de calcul

Comme les nœuds de calcul ne stockent physiquement aucune donnée et qu'ils sont destinés à prendre en charge l'exécution de requêtes, leur profil matériel peut être adapté à ces besoins, par exemple en privilégiant la mémoire et le processeur et en limitant le stockage au strict minimum. L'ingestion est transmise aux nœuds de données, soit directement par le pilote (xDBC, Spark), soit implicitement par le code du gestionnaire de sharding lorsque le code d'application "nu" s'exécute sur un nœud de calcul.

Illustrations de cluster sharded

Le déploiement d'un cluster sharded peut se faire de différentes manières. Les diagrammes de haut niveau suivants sont fournis pour illustrer les modèles de déploiement les plus courants.  Ces diagrammes n'incluent pas les passerelles et les détails du réseau et se concentrent uniquement sur les composants du cluster sharded.

Cluster sharded de base

Le schéma suivant représente le cluster sharded le plus simple avec quatre nœuds de données déployés dans une seule région et dans une seule zone.  Un équilibreur de charge AWS Elastic Load Balancer (ELB) est utilisé pour distribuer les connexions des clients à l'un des nœuds du cluster sharded 

Figure 9.3.1-a: Basic Sharded Cluster 

Dans ce modèle de base, il n'y a pas de résilience ou de haute disponibilité au-delà de ce que AWS fournit pour une seule machine virtuelle et son stockage SSD persistant attaché.  Deux adaptateurs d'interface réseau distincts sont recommandés pour assurer à la fois l'isolation de la sécurité du réseau pour les connexions client entrantes et l'isolation de la bande passante entre le trafic client et les communications du cluster sharded.

Cluster Sharded de base avec haute disponibilité

Le diagramme suivant représente le cluster sharded le plus simple avec quatre nœuds de données miroir déployés dans une seule région et divisant le miroir de chaque nœud entre les zones.  Un équilibreur de charge AWS est utilisé pour distribuer les connexions des clients à l'un des nœuds du cluster sharded.  

La haute disponibilité est assurée par l'utilisation de la mise en miroir des bases de données InterSystems, qui maintient un miroir répliqué de manière synchrone dans une zone secondaire de la région.

Trois adaptateurs d'interface réseau distincts sont recommandés pour assurer à la fois l'isolation de la sécurité du réseau pour les connexions client entrantes et l'isolation de la bande passante entre le trafic client, les communications du cluster sharded et le trafic du miroir synchrone entre les paires de nœuds.

Figure 9.3.2-a : Cluster sharded de base avec haute disponibilité 

Ce modèle de déploiement introduit également un arbitre miroir tel que celui décrit dans une section précédente de cet article.

Cluster sharded avec des nœuds de calcul séparés

Le diagramme suivant développe le cluster sharded pour une concurrence massive entre les utilisateurs et les requêtes avec des nœuds de calcul séparés et quatre nœuds de données. Le pool de serveurs Cloud Load Balancer contient uniquement les adresses des nœuds de calcul.  Les mises à jour et l'ingestion de données continueront d'être effectuées directement sur les nœuds de données, comme auparavant, afin de maintenir des performances à très faible latence et d'éviter les interférences et l'encombrement des ressources entre les charges de travail de requête/analyse provenant de l'ingestion de données en temps réel. 

Grâce à ce modèle, l'allocation des ressources peut être affinée pour la mise à l'échelle des calculs/requêtes et de l'ingestion de manière indépendante, ce qui permet d'optimiser les ressources là où elles sont nécessaires, en "juste à temps", et de conserver une solution économique mais simple, au lieu de gaspiller inutilement des ressources pour la mise à l'échelle des calculs ou des données.  

Les nœuds de calcul se prêtent à une utilisation très simple du regroupement automatique AWS (alias Autoscaling) pour permettre l'ajout ou la suppression automatique d'instances d'un groupe d'instances géré en fonction de l'augmentation ou de la diminution de la charge. L'autoscaling fonctionne en ajoutant des instances à votre groupe d'instances lorsqu'il y a plus de charge (upscaling), et en supprimant des instances lorsque le besoin d'instances diminue (downscaling).

Les détails de la mise à l'échelle automatique d'AWS ssont disponibles ici.

Figure 9.3.3-a : Cluster Sharded avec des nœuds de calcul et de données séparés

L'auto-scaling aide les applications basées sur le cloud à gérer de manière élégante les augmentations de trafic et réduit les coûts lorsque le besoin en ressources est moindre. Il suffit de définir la politique et l'auto-mesureur effectue une mise à l'échelle automatique en fonction de la charge mesurée.

Opérations de sauvegarde

Il existe de multiples options pour les opérations de sauvegarde.  Les trois options suivantes sont viables pour votre déploiement AWS avec InterSystems IRIS. 

TLes deux premières options, détaillées ci-dessous, 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 de 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 instantanées :

• Pause des écritures dans la base de données via un appel de la base de données External Freeze API.
• Créez des instantanés de l'OS + des disques de données.
• Reprendre les écritures de la base de données via l'appel External Thaw API..
• Sauvegarde des archives de l'installation vers un emplacement de sauvegarde

Les détails de External Freeze/Thaw API sont disponibles ici.

La troisième option est la sauvegarde en ligne InterSystems.  Il s'agit d'une approche d'entrée de gamme pour les petits déploiements avec un cas d'utilisation et une interface très simples.  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.  

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

Le choix de l'option à utiliser dépend des exigences et des politiques opérationnelles de votre organisation. InterSystems est à votre disposition pour discuter plus en détail des différentes options.

Sauvegarde des instantanés de l'AWS Elastic Block Store (EBS)

Les opérations de sauvegarde peuvent être réalisées à l'aide de l'API de ligne de commande AWS CLI et des capacités API ExternalFreeze/Thaw d'InterSystems. Cela permet 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.  Les détails de la gestion, de la création et de l'automatisation des snapshots AWS EBS sont disponibles à l'adresse suivante ici.

Instantanés du Logical Volume Manager (LVM)

Il est également possible d'utiliser un grand nombre d'outils de sauvegarde tiers disponibles sur le marché en déployant des agents de sauvegarde individuels dans la VM elle-même et en exploitant les sauvegardes au niveau des fichiers conjointement avec les instantanés du Logical Volume Manager (LVM).

L'un des principaux avantages de ce modèle est la possibilité d'effectuer des restaurations au niveau des fichiers des machines virtuelles basées sur Windows ou Linux.  Il convient de noter que, comme AWS et la plupart des autres fournisseurs de cloud IaaS ne fournissent pas de bandes magnétiques, tous les référentiels de sauvegarde sont sur disque pour l'archivage à court terme et peuvent exploiter un stockage à faible coût de type blob ou bucket pour la rétention à long terme (LTR).  Si vous utilisez cette méthode, il est fortement recommandé d'utiliser un produit de sauvegarde qui prend en charge les technologies de déduplication afin d'utiliser le plus efficacement possible les référentiels de sauvegarde sur disque.

Quelques exemples de ces produits de sauvegarde ayant une prise en charge dans le cloud incluent, sans y être limités, sont les suivants :  Commvault, EMC Networker, HPE Data Protector et Veritas Netbackup.  InterSystems ne valide ni n'approuve un produit plutôt qu'un autre. 

Sauvegarde en ligne

Pour les petits déploiements, la fonction intégrée de sauvegarde en ligne Online Backup est également une option viable.  Cet utilitaire de sauvegarde en ligne des bases de données InterSystems sauvegarde les données dans les fichiers de base 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 pas causer de temps d'arrêt aux utilisateurs du système de production. Les détails de la sauvegarde en ligne sont disponibles ici.

Dans AWS, une fois la sauvegarde en ligne terminée, le fichier de sortie de la sauvegarde et tous les autres fichiers utilisés par le système doivent être copiés vers un autre emplacement de stockage en dehors de cette instance de machine virtuelle.  Le stockage de type "Bucket/Object" est une bonne désignation pour cela. 

Il existe deux options pour utiliser un bucket AWS Single Storage Space (S3).  

• Utilisez les AWS CLIscripting APIs directement pour copier et manipuler les fichiers de sauvegarde en ligne (et autres fichiers non liés à la base de données) nouvellement créés
  • Les détails sont disponibles ici.
• Montez un volume Elastic File Store (EFS) et utilisez-le de la même manière qu'un disque persistant à faible coût.
  • Les détails de l'EFS sont disponibles ici.

Keywords:  IRIS, IntegratedML, Flask, FastAPI, Tensorflow servant, HAProxy, Docker, Covid-19

Objective:

Nous avons abordé quelques démonstrations rapides d'apprentissage profond et d'apprentissage automatique au cours des derniers mois, notamment un simple classificateur d'images radiographiques Covid-19 et un classificateur de résultats de laboratoire Covid-19 pour les admissions possibles en soins intensifs. Nous avons également évoqué une implémentation de démonstration IntegratedML du classificateur ICU. Alors que la randonnée de la "science des données" se poursuit, le moment est peut-être venu d'essayer de déployer des services d'IA du point de vue de "l'ingénierie des données" - pourrions-nous regrouper tout ce que nous avons abordé jusqu'à présent dans un ensemble d'API de services ? Quels sont les outils, les composants et l'infrastructure communs que nous pourrions exploiter pour réaliser une telle pile de services dans son approche la plus simple possible ?

Cadre

Dans le cadre de ce qui suit:

Pour commencer, nous pouvons simplement utiliser docker-compose pour déployer les composants dockerisés suivants dans un serveur AWS Ubuntu

• HAProxy - équilibreur de charge
• Gunicorn vs. Univorn ** - passerelle web **serveurs
• Flask vs. FastAPI - serveurs d'application pour l'interface utilisateur des applications Web, les définitions des API de service, la génération des cartes thermiques, etc.
• Tensorflow Model Serving vs. Tensorflow-GPU Model Serving - serveurs d'applications pour les classifications d'images, etc.
• IRIS IntegratedML - AutoML consolidé App+DB avec interface SQL.
• Python3 dans Jupyter Notebook pour émuler un client pour le benchmarking.
• Docker et docker-compose.
• AWS Ubuntu 16.04 avec un GPU Tesla T4  

Remarque:   Tensorflow Serving avec GPU n'est utilisé qu'à des fins de démonstration - vous pouvez simplement désactiver l'image liée au GPU (dans un fichier docker) et la configuration (dans le fichier docker-compose.yml).

Out of scope (Hors de portée) ou sur la prochaine liste de souhaits :

• **Les serveurs web Nginx ou Apache etc. sont omis dans la démo pour le moment.
• RabbitMQ et Redis - courtier de file d'attente pour une messagerie fiable qui peut être remplacé par IRIS ou Ensemble.
  IAM (Intersystems API Manger) ou Kong est sur la liste des souhaits.
• SAM(Intersystems System Alert & Monitoring)
• ICM (Intersystems Cloud Manager) avec l'opérateur Kubernetes - toujours l'un de mes préférés depuis sa naissance
• FHIR (serveur FHIR R4 basé sur Intesystems IRIS et FHIR Sandbox pour les applications SMART sur FHIR)
• Outils de développement CI/CD ou Github Actions.

De toute façon, un "ingénieur en apprentissage automatique" ("Machine Learning Engineer") mettra inévitablement la main sur ces composants pour fournir des environnements de production tout au long des cycles de vie des services. Nous pourrons en savoir plus au fil du temps.

Dépôt Github

Le code source complet se trouve à l'adresse suivante : https://github.com/zhongli1990/covid-ai-demo-deployment

Le référentiel integratedML-demo-template est également réutilisé avec le nouveau référentiel. 
 

Modèle de déploiement

Le schéma de déploiement logique de ce cadre de test "Démonstration de l'IA dans les Dockers" est présenté ci-dessous.

Pour la démonstration, j'ai délibérément créé deux piles distinctes pour la classification de l'apprentissage profond et le rendu web, puis j'ai utilisé un HAProxy comme équilibreur de charge pour distribuer les requêtes API entrantes entre ces deux piles de manière indépendante.

• Guniorn + Flask + Tensorflow Serving
• Univcorn + FaskAPI + Tensorflow Serving GPU

IRIS avec IntegratedML est utilisé pour les échantillons de démonstration d'apprentissage automatique, comme dans l'article précédent de prédiction de l'ICU.

J'ai omis certains composants communs dans la démo actuelle qui seraient nécessaires ou envisagés pour les services de production :

• Serveurs Web : Nginx ou Apache, etc. Ils seront nécessaires entre HAProxy et Gunicorn/Uvicorn, pour une gestion correcte des sessions HTTP, c'est-à-dire pour éviter les attaques DoS, etc.
• Gestionnaire de file d'attente et bases de données : RabbitMQ et/ou Redis, etc., entre Flask/FastAPI et le serveur backend, pour un service asynchrone fiable et la persistance des données/configurations, etc.
• Passerelle API : IAM ou Kong clusters, entre l'équilibreur de charge HAProxy et le serveur web pour la gestion des API sans créer de point singulier de défaillance.
• Surveillance et alerte : SAM serait bien.
• Provisionnement pour CI/CD devops : ICM avec K8s serait nécessaire pour le déploiement et la gestion neutre en nuage, et pour CI/CD avec d'autres outils devops communs.

En fait,  IRIS lui-même peut certainement être utilisé comme gestionnaire de file d'attente de niveau entreprise ainsi que comme base de données performante pour une messagerie fiable. Dans l'analyse des modèles, il apparaît qu'IRIS peut remplacer les courtiers de file d'attente et les bases de données RabbitMQ/Redis/MongoDB, etc., et qu'il serait donc mieux consolidé avec une latence bien moindre et de meilleures performances globales. Et plus encore, IRIS Web Gateway (anciennement CSP Gateway) peut certainement être positionné à la place de Gunicorn ou Unicorn, etc, n'est-ce pas ?  

Topologie de l'environnement

Il existe quelques options courantes pour mettre en œuvre le modèle logique ci-dessus dans tous les composants Docker. Les plus courantes sont les suivantes :  

• docker-compose
• docker swarm etc
• Kubernetes etc 
• ICM avec K8s Operation

Cette démonstration commence avec "docker-compose" pour un PoC fonctionnel et un certain benchmarking. Nous aimerions certainement utiliser K8s et peut-être aussi ICM au fil du temps. 

Comme décrit dans son fichier docker-compose.yml, une implémentation physique de sa topologie d'environnement sur un serveur AWS Ubuntu ressemblerait à ceci :  

Le diagramme ci-dessus montre comment ces ports de service de toutes les instances Docker sont mappés et exposés directement sur le serveur Ubuntu à des fins de démonstration. En production, la sécurité devrait être renforcée. Et pour les besoins de la démonstration, tous les conteneurs sont connectés au même réseau Docker, alors qu'en production, il serait séparé en routable externe et non-routable interne.

Composants "Dockerisés" 

Le tableau ci-dessous montre comment les volumes de stockage de la machine hôte sont montés sur chaque instance de conteneur comme spécifié dans ce fichier docker-compose.yml : 

ubuntu@ip-172-31-35-104:/zhong/flask-xray$ tree ./ -L 2

./├── covid19                             (Les conteneurs Flask+Gunicorn et Tensorflow Serving seront montés ici)│├── app.py                                (Flask main app:  Les interfaces de l'application web et du service API sont définies et mises en œuvre ici)│├── covid19_models               (Les modèles Tensorflow sont publiés et versionnés ici pour la classification des images Le conteneur Tensorflow Serving avec CPU)│├── Dockerfile                          (Le serveur Flask avec Gunicorn:      CMD ["gunicorn", "app:app", "--bind", "0.0.0.0:5000", "--workers", "4", "--threads", "2"])│├── models                               (Modèles au format .h5 pour l'application Flask et démonstration API de la génération de heatmaps par grad-cam sur des radiographies.)│├── __pycache__│├── README.md│├── requirements.txt             (Paquets Python nécessaires pour les applications complètes de Flask+Gunicorn) │├── scripts│├── static                                  (Fichiers statiques Web)│├── templates                         (Modèles de rendu Web)│├── tensorflow_serving        (Fichier de configuration pour le service de tensorflow)│└── test_images├── covid-fastapi                   (Les conteneurs FastAPI+Uvicorn et Tensorflow Serving avec GPU seront définis ici)│├── covid19_models            (Les modèles Tensorflow au service des GPU sont publiés et versionnés ici pour la classification des images)│├── Dockerfile                       (Le serveur Uvicorn+FastAPI sera lancé ici: CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--workers", "4" ])│├── main.py                           (FastAPI app: les interfaces de l'application web et du service API sont définies et mises en œuvre ici)│├── models                            (Modèles au format .h5 pour l'application FastAPI et démonstration API de la génération de heatmaps par grad-cam sur des radiographies)│├── __pycache__│├── README.md│├── requirements.txt│├── scripts│├── static│├── templates│├── tensorflow_serving│└── test_images├── docker-compose.yml      (Full stack Docker definition file.  La version 2.3 est utilisée pour tenir compte du GPU Docker "nvidia runtime", sinon la version 3.x peut être utilisée)├── haproxy                             (Le service docker HAProxy est défini ici.  Note : une session collante peut être définie pour le backend LB. )                             │├── Dockerfile│└── haproxy.cfg└── notebooks                       (Le service conteneur Jupyter Notebook avec Tensorflow 2.2 et Tensorboard etc)├── Dockerfile├── notebooks                  (Exemples de fichiers notebook pour émuler des applications API Client externes pour les tests fonctionnels et les tests de référence API en Python sur l'équilibreur de charge, etc)└── requirements.txt

Remarque: Le docker-compose.yml ci-dessus est destiné à la démonstration d'apprentissage profond de Convid X-Rays. Il est utilisé avec le docker-compose.yml d'un autre integratedML-demo-template pour former la pile de services complète, comme indiqué dans la topologie de l'environnement.  

Démarrage des services 

Un simple docker-compose up -d permettrait de démarrer tous les services de conteneurs :

ubuntu@ip-172-31-35-104:~$ docker ps
ID DE CONTENEUR        IMAGE                                 COMMANDE                  STATUT CRÉÉ                PORTS                                                                              NOMS
31b682b6961d        iris-aa-server:2020.3AA               "/iris-main"             Il y a 7 semaines         Jusqu'à 2 jours (en bonne santé)   2188/tcp, 53773/tcp, 54773/tcp, 0.0.0.0:8091->51773/tcp, 0.0.0.0:8092->52773/tcp   iml-template-master_irisimlsvr_1
6a0f22ad3ffc        haproxy:0.0.1                         "/docker-entrypoint.…"   Il y a 8 semaines         Jusqu'à 2 jours             0.0.0.0:8088->8088/tcp                                                             flask-xray_lb_1
71b5163d8960        ai-service-fastapi:0.2.0              "uvicorn main:app --…"   Il y a 8 semaines         Jusqu'à 2 jours             0.0.0.0:8056->8000/tcp                                                             flask-xray_fastapi_1
400e1d6c0f69        tensorflow/serving:latest-gpu         "/usr/bin/tf_serving…"   Il y a 8 semaines         Jusqu'à 2 jours             0.0.0.0:8520->8500/tcp, 0.0.0.0:8521->8501/tcp                                     flask-xray_tf2svg2_1
eaac88e9b1a7        ai-service-flask:0.1.0                "gunicorn app:app --…"   Шl y a 8 semaines         Jusqu'à 2 jours             0.0.0.0:8051->5000/tcp                                                             flask-xray_flask_1
e07ccd30a32b        tensorflow/serving                    "/usr/bin/tf_serving…"   Il y a 8 semaines         Jusqu'à 2 jours             0.0.0.0:8510->8500/tcp, 0.0.0.0:8511->8501/tcp                                     flask-xray_tf2svg1_1
390dc13023f2        tf2-jupyter:0.1.0                     "/bin/sh -c '/bin/ba…"   Il y a 8 semaines         Jusqu'à 2 jours             0.0.0.0:8506->6006/tcp, 0.0.0.0:8586->8888/tcp                                     flask-xray_tf2jpt_1
88e8709404ac        tf2-jupyter-jdbc:1.0.0-iml-template   "/bin/sh -c '/bin/ba…"   Il y a 2 $ois         Jusqu'à 2 jours             0.0.0.0:6026->6006/tcp, 0.0.0.0:8896->8888/tcp                                     iml-template-master_tf2jupyter_1

docker-compose up --scale fastapi=2 --scale flask=2 -d   par exemple, sera mis à l'échelle horizontalement jusqu'à 2 conteneurs Gunicorn+Flask et 2 conteneurs Univcorn+FastAPI :

ubuntu@ip-172-31-35-104:/zhong/flask-xray$ docker ps
ID DE CONTENEUR        IMAGE                                 COMMANDE                  STATUT CRÉÉ                PORTS                                                                              NOMS
dbee3c20ea95        ai-service-fastapi:0.2.0              "uvicorn main:app --…"   Il y a 4 minutes Jusqu'à 4 minutes          0.0.0.0:8057->8000/tcp                                                             flask-xray_fastapi_2
95bcd8535aa6        ai-service-flask:0.1.0                "gunicorn app:app --…"   Il y a 4 minutes Jusqu'à 4 minutes          0.0.0.0:8052->5000/tcp                                                             flask-xray_flask_2

... ...

L'exécution d'un autre "docker-compose up -d" dans le répertoire de travail de "integrtedML-demo-template" a fait apparaître le conteneur irisimlsvr et tf2jupyter dans la liste ci-dessus.

Tests

1. Application web de démonstration de l'IA avec une interface utilisateur simple

Après avoir démarré les services docker ci-dessus, nous pouvons visiter une application web de démonstration pour X-Ray Covid-19 lung detection hébergée dans une instance AWS EC2 à une adresse temporaire à http://ec2-18-134-16-118.eu-west-2.compute.amazonaws.com:8056/

Voici ci-dessous quelques écrans capturés depuis mon mobile. L'interface utilisateur de démonstration est très simple : en gros, je clique sur "Choose File" puis sur le bouton "Submit" pour télécharger une image radiographique, puis l'application affiche un rapport de classification. S'il s'agit d'une radiographie Covid-19, une [carte thermique sera affichée] (https://community.intersystems.com/post/explainability-and-visibility-covid-19-x-ray-classifiers-deep-learning) pour reproduire la zone de lésion "détectée" par DL ; sinon, le rapport de classification ne montrera que l'image radiographique téléchargée.

L'application web est une page serveur Python dont la logique est principalement codée dans le fichier main.py de FastAPI, ainsi que dans le fichier app.py de Flask.

Quand j'aurai un peu plus de temps libre, je pourrais documenter en détail les différences de codage et de convention entre Flask et FastAPI. En fait, j'espère pouvoir faire un hébergement de démonstration Flask vs FastAPI vs IRIS pour l'IA. 

2. Test des API de démonstration      

FastAPI (exposé au port 8056) a intégré des documents Swagger API, comme indiqué ci-dessous. C'est très pratique. Tout ce que j'ai à faire est d'utiliser "/docs" dans son URL, par exemple : 

J'ai intégré quelques paramètres (tels que /hello et /items) et quelques interfaces API de démonstration (telles que /healthcheck, /predict, et predict/heatmap).

Testons rapidement ces API, en exécutant quelques lignes Python (en tant qu'émulateur d'application client API) dans l'un des [fichiers d'échantillons de Jupyter Notebook que j'ai créés] (https://github.com/zhongli1990/covid-ai-demo-deployment/tree/master/notebooks/notebooks) pour ce service de démonstration de l'IA.  

Ci-dessous, j'exécute ce fichier à titre d'exemple : https://github.com/zhongli1990/covid-ai-demo-deployment/blob/master/notebooks/notebooks/Covid19-3class-Heatmap-Flask-FastAPI-TF-serving-all-in-one-HAProxy2.ipynb

Tout d'abord pour tester que le backend TF-Serving (port 8511) et TF-Serving-GPU (port 8521) sont en place et fonctionnent : 

!curl http://172.17.0.1:8511/v1/models/covid19  # servant tensorflow
!curl http://172.17.0.1:8521/v1/models/covid19  # servant tensorflow-gpu

{
 "model_version_status": [
  {
   "version": "2",
   "state": "AVAILABLE",
   "status": {
    "error_code": "OK",
    "error_message": ""
   }
  }
 ]
}
{
 "model_version_status": [
  {
   "version": "2",
   "state": "AVAILABLE",
   "status": {
    "error_code": "OK",
    "error_message": ""
   }
  }
 ]
}

Ensuite, vérifiez que les services API suivants sont en place et fonctionnent :

r = requests.get('http://172.17.0.1:8051/covid19/api/v1/healthcheck')  # tf servant le docker avec le cpu
print(r.status_code, r.text)
r = requests.get('http://172.17.0.1:8056/covid19/api/v1/healthcheck')  # tf-servant le docker avec le gpu
print(r.status_code, r.text)
r = requests.get('http://172.17.0.1:8088/covid19/api/v1/healthcheck')  # tf-servant le docker avec le HAproxy
print(r.status_code, r.text)

Et les résultats attendus seraient :

200 L'API du détecteur Covid19 est en ligne !
200 "L'API du détecteur Covid19 est en ligne !\n\n"
200 "L'API du détecteur Covid19 est en ligne !\n\n"

Tester une interface API fonctionnelle, telle que **/predict/heatmap ** pour renvoyer le résultat de la classification et de la heatmap d'une image radiographique d'entrée. L'image entrante est codée en based64 avant d'être envoyée via HTTP POST conformément aux définitions de l'API :

%%time# Importation de la bibliothèque des requêtes
import argparse
import base64import requests# définition d'un point d'entrée ap pour api
API_ENDPOINT = "http://172.17.0.1:8051/covid19/api/v1/predict/heatmap"image_path = './Covid_M/all/test/covid/nejmoa2001191_f3-PA.jpeg'
#image_path = './Covid_M/all/test/normal/NORMAL2-IM-1400-0001.jpeg'
#image_path = './Covid_M/all/test/pneumonia_bac/person1940_bacteria_4859.jpeg'
b64_image = ""
# Encoding the JPG,PNG,etc. image to base64 format
with open(image_path, "rb") as imageFile:
    b64_image = base64.b64encode(imageFile.read())# données à envoyer à l'api
data = {'b64': b64_image}# envoi d'une requête post et enregistrement de la réponse en tant qu'objet réponse
r = requests.post(url=API_ENDPOINT, data=data)print(r.status_code, r.text)# extraction de la réponse
print("{}".format(r.text))

Toutes ces [images de test ont également été téléchargées sur GitHub] (https://github.com/zhongli1990/Covid19-X-Rays/tree/master/all/test). Le résultat du code ci-dessus sera comme ça:

200 {"Input_Image":"http://localhost:8051/static/source/0198f0ae-85a0-470b-bc31-dc1918c15b9620200906-170443.png","Output_Heatmap":"http://localhost:8051/static/result/Covid19_98_0198f0ae-85a0-470b-bc31-dc1918c15b9620200906-170443.png.png","X-Ray_Classfication_Raw_Result":[[0.805902302,0.15601939,0.038078323]],"X-Ray_Classification_Covid19_Probability":0.98,"X-Ray_Classification_Result":"Covid-19 POSITIVE","model_name":"Customised Incpetion V3"}

{"Input_Image":"http://localhost:8051/static/source/0198f0ae-85a0-470b-bc31-dc1918c15b9620200906-170443.png","Output_Heatmap":"http://localhost:8051/static/result/Covid19_98_0198f0ae-85a0-470b-bc31-dc1918c15b9620200906-170443.png.png","X-Ray_Classfication_Raw_Result":[[0.805902302,0.15601939,0.038078323]],"X-Ray_Classification_Covid19_Probability":0.98,"X-Ray_Classification_Result":"Covid-19 POSITIVE","model_name":"Customised Incpetion V3"}

CPU times: user 16 ms, sys: 0 ns, total: 16 ms
Wall time: 946 ms

3. Les applications de démonstration de services pour les tests benchmarkés

Nous avons mis en place une instance d'équilibreur de charge HAProxy. Nous avons également démarré un service Flask avec 4 travailleurs, et un service FastAPI avec 4 travailleurs également.

Pourquoi ne pas créer 8x processus Pyhon directement dans le fichier Notebook, pour émuler 8x clients API simultanés envoyant des requêtes dans les API du service de démonstration, pour voir ce qui se passe ? 

#from concurrent.futures import ThreadPoolExecutor as PoolExecutor
from concurrent.futures import ProcessPoolExecutor as PoolExecutor
import http.client
import socket
import timestart = time.time()#laodbalancer:
API_ENDPOINT_LB = "http://172.17.0.1:8088/covid19/api/v1/predict/heatmap"
API_ENDPOINT_FLASK = "http://172.17.0.1:8052/covid19/api/v1/predict/heatmap"
API_ENDPOINT_FastAPI = "http://172.17.0.1:8057/covid19/api/v1/predict/heatmap"
def get_it(url):
    try:
        # boucle sur les images
        for imagePathTest in imagePathsTest:
            b64_image = ""
            with open(imagePathTest, "rb") as imageFile:
                b64_image = base64.b64encode(imageFile.read())

            data = {'b64': b64_image}
            r = requests.post(url, data=data)
            #print(imagePathTest, r.status_code, r.text)
        return r
    except socket.timeout:
        # dans un scénario du monde réel, vous feriez probablement quelque chose si le
        # socket passe en timeout
        passurls = [API_ENDPOINT_LB, API_ENDPOINT_LB,
        API_ENDPOINT_LB, API_ENDPOINT_LB,
        API_ENDPOINT_LB, API_ENDPOINT_LB,
        API_ENDPOINT_LB, API_ENDPOINT_LB]with PoolExecutor(max_workers=16) as executor:
    for _ in executor.map(get_it, urls):
        pass

print("--- %s seconds ---" % (time.time() - start))

Il a donc fallu 74 secondes pour traiter 8x27 = 216 images de test. Cette pile de démonstration à charge équilibrée était capable de traiter 3 images par seconde (en renvoyant les résultats de la classification et de la heatmap aux clients) :

--- 74.37691688537598 seconds ---

À partir de la commande Top de la session Putty, nous pouvons voir que 8x processus de serveur (4x gunicorn + 4 unicorn/python) ont commencé à monter en puissance dès que les scripts de référence ci-dessus ont commencé à être exécutés.

Suivant

Cet article n'est qu'un point de départ pour mettre en place une pile de déploiement "All-in-Docker AI demo" comme cadre de test. J'espère ensuite ajouter d'autres interfaces de démonstration API, telles que l'interface de prédiction des soins intensifs Covid-19, idéalement conforme à la norme FHIR R4, etc. Cela pourrait également être un banc d'essai pour explorer une intégration plus étroite avec les capacités ML hébergées par IRIS. Au fil du temps, il peut être utilisé comme un cadre de test (et un cadre assez simple) pour intercepter de plus en plus de modèles ML ou DL spécialisés au fur et à mesure que nous avançons sur divers aspects de l'IA, notamment l'imagerie médicale, la santé de la population ou la prédiction personnalisée, le traitement automatique des langues, etc. J'ai également dressé une liste de souhaits à la toute fin de l'article précédent (dans sa section "Next" (Suivant)). 

Annonce de l'interface utilisateur Web InterSystems Container Registry

InterSystems a le plaisir d'annoncer la sortie de l'interface utilisateur Web InterSystems Container Registry. Cet outil est conçu pour faciliter la découverte, l'accès et l'utilisation des nombreuses images de conteneurs hébergées sur ICR.

L'interface utilisateur d'InterSystems Container Registry est disponible à l'adresse: https://containers.intersystems.com/contents

Docker 20.10.14 (publié le 23 mars 2022) modifie les capacités Linux accordées aux conteneurs d'une manière incompatible avec le vérificateur de capacités Linux dans les conteneurs InterSystems IRIS 2021.1 (et versions ultérieures).

Les utilisateurs exécutant Docker 20.10.14 sous Linux constateront que les conteneurs IRIS 2021.1+ ne démarreront pas et les journaux signaleront à tort que les fonctionnalités Linux requises sont manquantes. Par example :

[ERROR] Required Linux capability cap_setuid is missing.
[ERROR] Required Linux capability cap_dac_override is missing.
[ERROR] Required Linux capability cap_fowner is missing.
[ERROR] Required Linux capability cap_setgid is missing. 
[ERROR] Required Linux capability cap_kill is missing.
[FATAL] Your IRIS container is missing one or more required Linux capabilities.

Quoi faire

Les utilisateurs rencontrant ce problème devront ajuster la ligne de commande transmise au point d'entrée du conteneur pour désactiver la vérification des fonctionnalités Linux. À partir de la ligne de commande, ajoutez --check-caps false après l'image dans votre commande docker run ou docker start. Par example :

docker run containers.intersystems.com/intersystems/iris-community:2022.1.0.152.0 --check-caps false

Si vous utilisez docker-compose, le changement correspondant serait le suivant :

  command: --check-caps false

La vérification de capacité agit comme un moyen de vérifier les erreurs de configuration courantes avant de démarrer les processus IRIS. La désactivation de la vérification des capacités Linux n'a aucun impact sur les processus IRIS exécutés dans le conteneur.

En savoir plus

• Docker 20.10.14 release notes
• Running InterSystems Products in Containers

La version 3.3 d'InterSystems Kubernetes Operation (IKO) est désormais disponible via la page de téléchargement WRC et le registre de conteneurs InterSystems.

IKO simplifie le travail avec InterSystems IRIS ou InterSystems IRIS for Health dans Kubernetes en fournissant une définition de ressource irisCluster facile à utiliser. Consultez la documentation pour une liste complète des fonctionnalités, y compris le sharding, le mirroring et la configuration d'ECP.

Faits saillants de l'IKO 3.3 :

• Le support des éditions 2021.2 et 2022.1 d'InterSystems IRIS et IRIS for Health
• Le support de Kuberentes 1.21
• Déployez des configurations communes d'Alerte et de Surveillance du Système (ASS) dans le cadre de votre irisCluster
• InterSystems API Manager (IAM) peut désormais également être déployé et géré dans le cadre de votre irisCluster
• Balisage automatique du côté actif de la paire de miroirs, de sorte qu'un service puisse toujours pointer vers le miroir actif.