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 !

Si vous utilisez IRIS dans une configuration miroir pour HA dans AWS, la question de la fourniture d'un Miroir VIP (IP virtuelle) devient pertinente. L'IP virtuelle permet aux systèmes en aval d'interagir avec IRIS en utilisant une seule adresse IP. Même en cas de basculement, les systèmes en aval peuvent se reconnecter à la même adresse IP et continuer à travailler.

Le principal problème, lors du déploiement sur AWS, est qu'un VIP IRIS exige que les deux membres du miroir soient dans le même sous-réseau, d'après les docs :

Pour utiliser un miroir VIP, les deux membres du basculement doivent être configurés dans le même sous-réseau et le VIP doit appartenir au même sous-réseau que l'interface réseau sélectionnée sur chaque système.

Cependant, pour obtenir l'HA, les membres du miroir IRIS doivent être déployés dans des zones de disponibilité différentes, ce qui signifie des sous-réseaux différents (car les sous-réseaux ne peuvent être que dans un seul az). L'une des solutions pourrait être les équilibreurs de charge, mais ils (A) coûtent cher, et (B) si vous devez acheminer du trafic non-HTTP (comme TCP pour HL7), vous devrez utiliser des équilibreurs de charge de réseau avec une limite de 50 ports au total.

Dans cet article, je voudrais fournir un moyen de configurer un Mirror VIP sans utiliser l'équilibrage de la charge du réseau suggéré dans la plupart des autres architectures de référence AWS. En production, nous avons trouvé des limitations qui entravaient les solutions avec le coût, les limites de 50 auditeurs, les dépendances DNS et la nature dynamique des deux adresses IP qu'AWS fournit à travers les zones de disponibilité.

Architecture

Nous avons un VPC avec trois sous-réseaux privés (je simplifie ici - bien sûr, vous aurez probablement des sous-réseaux publics, un arbitre dans une autre AZ, et ainsi de suite, mais c'est un minimum absolu suffisant pour démontrer cette approche). Le VPC se voit allouer des IPs : 10.109.10.1 à 10.109.10.254 ; les sous-réseaux (dans différents AZs) sont : 10.109.10.1 à 10.109.10.62, 10.109.10.65 à 10.109.10.126, et 10.109.10.224 à 10.109.10.254.

Implementation d'un VIP

1. Sur chaque instance EC2 (SourceDestCheck doit être définie sur false), nous allons allouer la même adresse IP sur l'interface réseau eth0:1. Cette adresse IP se trouve dans la plage CIDR du VPC - dans une zone VIP spéciale. Par exemple, nous pouvons utiliser la dernière IP d'une plage - 10.109.10.254 :

cat << EOFVIP >> /etc/sysconfig/network-scripts/ifcfg-eth0:1
          DEVICE=eth0:1
          ONPARENT=on
          IPADDR=10.109.10.254
          PREFIX=27
          EOFVIP
sudo chmod -x /etc/sysconfig/network-scripts/ifcfg-eth0:1
sudo ifconfig eth0:1 up

En fonction du système d'exploitation, vous pouvez avoir besoin d'exécuter :

ifconfig eth0:1
systemctl restart network

2. En cas de basculement du miroir, mettre à jour la table de routage pour qu'elle pointe vers l'eni sur le nouveau primaire. Nous utiliserons un rappel ZMIRROR pour mettre à jour le tableau de routage après que le membre du miroir actuel soit devenu le primaire. Ce code utilise Python intégré pour :

• Obtenir l'IP sur eth0:1
• Obtenir l'InstanceId et la Région à partir des métadonnées de l'instance
• Trouver le tableau des routes principales pour le VPC EC2
• Supprimer l'ancienne route, s'il y en a une
• Ajouter une nouvelle route pointant vers elle-même

Le code:

import os
import urllib.request
import boto3
from botocore.exceptions import ClientError

PRIMARY_INTERFACE = 'eth0'
VIP_INTERFACE = 'eth0:1'

eth0_addresses = [
    line
    for line in os.popen(f'ip -4 addr show dev {PRIMARY_INTERFACE}').read().split('\n')
    if line.strip().startswith('inet')
]

VIP = None
for address in eth0_addresses:
    if address.split(' ')[-1] == VIP_INTERFACE:
        VIP = address.split(' ')[5]

if VIP is None:
    raise ValueError('Échec de la récupération d'un VIP valide !')

# Recherche de l'ID de l'instance du membre du miroir actuel
instanceid = (
    urllib.request.urlopen('http://169.254.169.254/latest/meta-data/instance-id')
    .read()
    .decode()
)

region = (
    urllib.request.urlopen('http://169.254.169.254/latest/meta-data/placement/region')
    .read()
    .decode()
)

session = boto3.Session(region_name=region)
ec2Resource = session.resource('ec2')
ec2Client = session.client('ec2')
instance = ec2Resource.Instance(instanceid)

# Recherche de l'ID du tableau de routage principal pour ce VPC
vpc = ec2Resource.Vpc(instance.vpc.id)

for route_table in vpc.route_tables.all():
    # Mise à jour du tableau de routage principal pour pointer vers cette instance
    try:
        ec2Client.delete_route(
            DestinationCidrBlock=VIP, RouteTableId=str(route_table.id)
        )
    except ClientError as exc:
        if exc.response['Error']['Code'] == 'InvalidRoute.NotFound':
            print('Rien à supprimer, continuer')
        else:
            raise exc
    # Ajout de la nouvelle route
    ec2Client.create_route(
        DestinationCidrBlock=VIP,
        NetworkInterfaceId=instance.network_interfaces[0].id,
        RouteTableId=str(route_table.id),
    )

et le même code comme routine ZMIRROR :

NotifyBecomePrimary() PUBLIC {
  try {
    set dir = $system.Util.ManagerDirectory()_ "python"
    do ##class(%File).CreateDirectoryChain(dir)

    try {
      set boto3 = $system.Python.Import("boto3")
    } catch {
      set cmd = "pip3"
      set args($i(args)) = "install"
      set args($i(args)) = "--target"
      set args($i(args)) = dir
      set args($i(args)) = "boto3"
      set sc = $ZF(-100,"", cmd, .args)
      // pour python précédant la version 3.7, installer également dataclasses
      set boto3 = $system.Python.Import("boto3")
    }
    kill boto3

    set code =  "import os" _ $c(10) _
				"import urllib.request" _ $c(10) _
				"import boto3" _ $c(10) _
				"from botocore.exceptions import ClientError" _ $c(10) _
				"PRIMARY_INTERFACE = 'eth0'" _ $c(10) _
				"VIP_INTERFACE = 'eth0:1'" _ $c(10) _
				"eth0_addresses = [" _ $c(10) _
				"    line" _ $c(10) _
				"    for line in os.popen(f'ip -4 addr show dev {PRIMARY_INTERFACE}').read().split('\n')" _ $c(10) _
				"    if line.strip().startswith('inet')" _ $c(10) _
				"]" _ $c(10) _
				"VIP = None" _ $c(10) _
				"for address in eth0_addresses:" _ $c(10) _
				"    if address.split(' ')[-1] == VIP_INTERFACE:" _ $c(10) _
				"        VIP = address.split(' ')[5]" _ $c(10) _
				"if VIP is None:" _ $c(10) _
				"    raise ValueError('Échec de la récupération d'un VIP valide !')" _ $c(10) _
				"# Recherche de l'ID de l'instance du membre du miroir actuel" _ $c(10) _
				"instanceid = (" _ $c(10) _
				"    urllib.request.urlopen('http://169.254.169.254/latest/meta-data/instance-id')" _ $c(10) _
				"    .read()" _ $c(10) _
				"    .decode()" _ $c(10) _
				")" _ $c(10) _
				"region = (" _ $c(10) _
				"    urllib.request.urlopen('http://169.254.169.254/latest/meta-data/placement/region')" _ $c(10) _
				"    .read()" _ $c(10) _
				"    .decode()" _ $c(10) _
				")" _ $c(10) _
				"session = boto3.Session(region_name=region)" _ $c(10) _
				"ec2Resource = session.resource('ec2')" _ $c(10) _
				"ec2Client = session.client('ec2')" _ $c(10) _
				"instance = ec2Resource.Instance(instanceid)" _ $c(10) _
				"# Recherche de l'ID du tableau de routage principal pour ce VPC" _ $c(10) _
				"vpc = ec2Resource.Vpc(instance.vpc.id)" _ $c(10) _
				"for route_table in vpc.route_tables.all():" _ $c(10) _
				"    # Mise à jour du tableau de routage principal pour pointer vers cette instance" _ $c(10) _
				"    try:" _ $c(10) _
				"        ec2Client.delete_route(" _ $c(10) _
				"            DestinationCidrBlock=VIP, RouteTableId=str(route_table.id)" _ $c(10) _
				"        )" _ $c(10) _
				"    except ClientError as exc:" _ $c(10) _
				"        if exc.response['Error']['Code'] == 'InvalidRoute.NotFound':" _ $c(10) _
				"            print('Rien à supprimer, continuer')" _ $c(10) _
				"        else:" _ $c(10) _
				"            raise exc" _ $c(10) _
				"    # Ajout de la nouvelle route" _ $c(10) _
				"    ec2Client.create_route(" _ $c(10) _
				"        DestinationCidrBlock=VIP," _ $c(10) _
				"        NetworkInterfaceId=instance.network_interfaces[0].id," _ $c(10) _
				"        RouteTableId=str(route_table.id)," _ $c(10) _
				"    )"


    set rc = $system.Python.Run(code)
    set sc = ##class(%SYS.System).WriteToConsoleLog("Attribution VIP " _ $case(rc, 0:"successful", :"error"), , $case(rc, 0:0, :1), "NotifyBecomePrimary:ZMIRROR")

  } catch ex {
    #dim ex As %Exception.General
    do ex.Log()
    set sc = ##class(%SYS.System).WriteToConsoleLog("Une exception a été détectée lors de I'attribution d'un VIP : " _ ex.DisplayString(), , 1, "NotifyBecomePrimary:ZMIRROR")
  }
  quit 1
}

Démarrage initial

NotifyBecomePrimary est aussi appelé automatiquement au démarrage du système (après la reconnexion des miroirs), mais si vous voulez que vos environnements non-miroirs acquièrent VIP de la même manière, utilisez la routine ZSTART routine:

SYSTEM() PUBLIC {
  if '$SYSTEM.Mirror.IsMember() {
    do NotifyBecomePrimary^ZMIRROR()
  }
  quit 1
}

Suppression

Si vous utilisez des outils de provisionnement automatique, comme CloudFormation, cette route doit être supprimée avant de pouvoir supprimer le sous-réseau. Vous pouvez ajouter le code de suppression à ^%ZSTOP, mais n'oubliez pas de vérifier $SYSTEM.Mirror.IsPrimary() parce que lorsque le miroir primaire s'arrête, pendant ^%ZSTOP il est toujours primaire. De manière générale, je recommanderais la suppression des routes externes dans le cadre d'un script d'outils de provisionnement.

Conclusion

Et c'est tout ! Dans le tableau de routage, nous obtenons une nouvelle route pointant vers un miroir primaire Primary actuel lorsque l'événement NotifyBecomePrimary se produit.

L'auteur tient à remercier Jared Trog et @sween pour la création de cette approche.

L'auteur tient à remercier @Tomohiro Iwamoto pour avoir testé cette approche et déterminé toutes les conditions requises pour qu'elle fonctionne.

Aperçu général

Des performances prévisibles en matière d'E/S de stockage avec une faible latence sont essentielles pour assurer l'évolutivité et la fiabilité de vos applications. Cette série de benchmarks a pour but d'informer les utilisateurs d'IRIS qui envisagent de déployer des applications dans AWS sur les performances des volumes EBS gp3.

Résumé

• Une bande LVM peut augmenter le nombre d'IOPS et le débit au-delà des limites de performance d'un volume EBS unique.
• Une bande LVM réduit la latence de lecture.

**À lire en premier ** Une architecture de référence, comprenant une explication plus détaillée de la configuration de LVM dans AWS, est disponible ici : https://community.intersystems.com/post/intersystems-iris-example-reference-architectures-amazon-web-services-aws

Besoin de savoir

Résumé des performances du volume EBS type gp3.

Les fournisseurs de services en nuage imposent des limites de performance de stockage, par exemple, IOPS ou débit, généralement en augmentant la latence, ce qui aura un impact sur la performance de l'application et l'expérience de l'utilisateur final. Avec les volumes gp3, les limites de performance de stockage de base peuvent être augmentées en payant des prix plus élevés pour augmenter les limites prédéfinies.

Notez que vous devez augmenter le nombre d'IOPS et le débit pour obtenir les performances maximales d'un volume EBS. La latence est appliquée lorsque l'une ou l'autre des limites est atteinte.

Performance IOPS

• Les volumes gp3 offrent une performance IOPS de base constante de 3 000 IOPS, qui est incluse dans le prix du stockage.
• Vous pouvez provisionner des IOPS supplémentaires jusqu'à un maximum de 16 000 IOPS par volume.
• Le maximum d'IOPS peut être provisionné pour les volumes de 32 GiB ou plus.
• Les volumes gp3 n'utilisent pas les performances en rafale.

Performances de débit

• Les volumes gp3 offrent un débit de base constant de 125 Mio/s, qui est inclus dans le prix du stockage.
• Vous pouvez provisionner un débit supplémentaire (jusqu'à un maximum de 1.000 Mio/s) pour un coût additionnel à un ratio de 0,25 Mio/s par IOPS provisionné.
• Le débit maximum peut être provisionné à 4.000 IOPS ou plus et 8 GiB ou plus (4.000 IOPS × 0,25 Mio/s par IOPS = 1.000 Mio/s).

Pour en savoir plus, consultez Volumes SSD à usage général - Amazon Elastic Compute Cloud.

Limites d'instance

• Les types d'instances EC2 ont des limites maximales d'IOP et de débit. La latence est appliquée lorsque les limites d'instance ou d'EBS sont atteintes.

Pour en savoir plus, consultez Instances Amazon EBS optimisées - Amazon Elastic Compute Cloud

Gestionnaire de volume logique (Linux)

Si votre application nécessite plus de 16 000 IOPS à partir d'un seul système de fichiers, vous pouvez configurer plusieurs volumes dans une bande LVM (gestionnaire de volumes logiques).

Par exemple : si vous avez besoin de 80 000 IOPS, vous pouvez provisionner un type d'instance EC2 capable de prendre en charge 80 000 IOPS à l'aide de cinq volumes gp3 en bandes LVM. 

LVM a été utilisé pour tous les tests suivants avec un ou plusieurs volumes EBS.

Autres types de stockage par blocs

Bien qu'il existe d'autres types de volumes, tels que io2 block express, avec des IOPS et des débits plus élevés pour un seul volume, il peut être beaucoup moins cher d'utiliser des volumes EBS type gp3 dans une bande LVM pour la même quantité de stockage et des IOPS "suffisamment élevés". io2 block express n'a de valeur que pour certains types d'instances.

Exécution des tests

Deux tests sont exécutés pour générer des simulations d'E/S de stockage de l'application IRIS. Il s'agit des tests RANREAD et RANWRITE.

Les détails de ces tests et la manière de les exécuter se trouvent ici : https://community.intersystems.com/post/perftools-io-test-suite

RANREAD

Ce test génère des lectures aléatoires d'une seule base de données d'IRIS.

• Dans IRIS, les lectures sont continues par les processus utilisateurs ; un processus utilisateur initie une entrée-sortie de disque pour lire les données. Les démons qui servent les pages web, les requêtes SQL ou les processus utilisateurs directs effectuent des lectures.
• Les processus RANREAD lisent des blocs de données aléatoires dans la base de données de test.
• La base de données de test est dimensionnée de manière à dépasser le cache de lecture attendu des systèmes de stockage sur site. On ne sait pas si AWS utilise la mise en cache de lecture (par exemple, Azure le fait par défaut).

RANWRITE

Génère des E/S d'écriture à l'aide du cycle du démon d'écriture de la base de données IRIS. Les trois principales activités d'écriture d'IRIS sont les suivantes :

• Journal d'écriture d'images (WIJ). Le WIJ écrit une rafale environ toutes les 80 secondes ou lorsqu'un pourcentage du cache de la base de données est en attente de mises à jour par un seul démon d'écriture du maître de la base de données. Le WIJ protège l'intégrité des fichiers de la base de données physique contre les défaillances du système pendant un cycle d'écriture de la base de données. Les écritures sont d'environ 256 Ko chacune juste avant que les fichiers de la base de données ne soient mis à jour par des écritures aléatoires de la base de données.
• Écritures aléatoires dans des bases de données. Les écritures de la base de données par le démon d'écriture se font en rafale environ toutes les 80 secondes ou en fonction du pourcentage de mises à jour en attente dans le cache de la base de données. Un ensemble de processus du système de base de données, connus sous le nom de démons d'écriture, effectue les écritures. Les processus utilisateur mettent à jour le cache en mémoire de la base de données et un déclencheur (basé sur un seuil de temps ou d'activité) envoie les mises à jour sur le disque à l'aide des démons d'écriture. En règle générale, quelques Mo à plusieurs Go sont écrits au cours du cycle d'écriture, en fonction des taux de transaction.
• Écritures de journal Les écritures dans le journal sont quasi-continues, de moins de deux secondes, et sont déclenchées lorsque les tampons du journal sont pleins ou lors d'une demande de synchronisation des données (par exemple, à partir d'une transaction). Les écritures de journal sont séquentielles et leur taille varie de 4 Ko à 4 Mo. Le nombre d'écritures par seconde peut varier de quelques dizaines à plusieurs milliers pour les grands déploiements utilisant des serveurs d'application distribués.

Note : des bases de données séparées sont utilisées pour RANREAD et RANWRITE dans les tests ; cependant, le même volume EBS et le même système de fichiers (/data) sont utilisés. La taille de la base de données RANREAD est de 700 Go. IRIS sur les systèmes Linux utilise l'IO directe pour les opérations de base de données. Le cache de page du système de fichiers Linux n'est pas utilisé.

Résultats de benchmarks

A. Absence de bande LVM

Le benchmark a été exécuté en utilisant l'instance EBS optimisée suivante :

Le benchmark IRIS est exécuté avec trois volumes EBS ( Données, WIJ, et Journaux). Les IOPS pour le volume /data ont été provisionnés au maximum pour un seul volume. Le débit a été laissé à la valeur par défaut de 125 Mo/s.

A.002 - RANREAD de 30 minutes seulement avec une augmentation progressive de l'IOPS.

Cinq puis dix processus RANREAD ont été utilisés pour générer l'IO. Approche du débit maximum (16K IOPS et 125 Mo/s de débit).

Note : IRIS utilise un bloc de base de données de 8 Ko (1 500 * 8 Ko = environ 123 Mio/s).

Dans l'image ci-dessous : La latence de base (en vert) est cohérente entre les exécutions de RANREAD, avec une moyenne de 0,7 à 1,5 ms, bien qu'il y ait des pics à plus de 5 ms. Pour une raison inconnue, les performances se dégradent au milieu du test à 10 processus.

A.006 - RANREAD et RANWRITE de 20 minutes.

L'image ci-dessous montre comment le test a été rythmé pour atteindre des pics autour de 8 000 IOPS en écriture et 12 000 IOPS en lecture. L'écart en lecture est intentionnel.

La latence de lecture dans l'image ci-dessous est similaire au test A.002. Les bases de données en lecture et en écriture sont sur le même volume EBS. Il y a un pic dans la latence de lecture (vert) pendant le cycle du démon d'écriture des écritures aléatoires de la base de données (bleu). Le pic de latence de lecture est transitoire et n'affectera probablement pas l'expérience d'un utilisateur interactif.

Le WIJ se trouve sur un volume EBS séparé afin d'isoler les écritures séquentielles du WIJ des IOPS de lecture. Bien que dans le nuage tout le stockage EBS soit un stockage réseau, il n'y a aucune garantie que les volumes EBS individuels soient dans un stockage SSD physique séparé ou que les différents volumes attachés à une instance soient dans le même boîtier de stockage.

B. Augmentation des IOPS et du débit à l'aide d'une bande LVM.

La suite de tests a été exécutée en utilisant une instance EBS optimisée avec un maximum de 80 000 IOPS :

Le benchmark IRIS fonctionne avec cinq volumes EBS. Remarque : le fichier /data comprend cinq volumes EBS dans une bande LVM.

B.080 - Le RANREAD de 30 minutes n'augmente que progressivement le nombre d'IOPS.

Le test a été effectué avec 10 à 50 processus RANREAD, en augmentant par paliers de 10 processus. Le test s'approche du maximum d'IOPS (80K).

La latence de lecture de la base de données est inférieure (0,7 en moyenne) à celle du test sans bande.

B.083 - RANREAD et RANWRITE de 30 minutes.

Ce test a été cadencé à des pics d'environ 40 000 IOPS en écriture et 60 000 IOPS en lecture.

Notez que les IOPS de lecture et d'écriture combinées sont supérieures aux IOPS maximales de l'instance EC2 (80 000 IOPS).

La latence de lecture est similaire à celle du test B.080. Les bases de données de lecture et d'écriture sont sur le même volume EBS. Il y a un pic dans la latence de lecture (vert) pendant le cycle du démon d'écriture des écritures aléatoires de la base de données (bleu). Le pic de latence de lecture est transitoire et inférieur à 1,4 ms et n'affectera probablement pas l'expérience de l'utilisateur.

 Aujourd'hui, la grande majorité des applications sont déployées sur des services de cloud public. Les avantages sont multiples : réduction des ressources humaines et matérielles nécessaires, possibilité d'évoluer rapidement et à moindre coût, plus grande disponibilité, fiabilité, évolutivité élastique et options permettant d'améliorer la protection des actifs numériques. L'une des options les plus prisées est le Google Cloud. Il nous permet de déployer nos applications à l'aide de machines virtuelles (Compute Engine), de conteneurs Docker (Cloud Run) ou de Kubernetes (Kubernetes Engine). Le premier n'utilise pas Docker. Elle utilise plutôt une machine virtuelle sous Windows ou Linux où vous installez votre serveur d'application et déployez votre application. Les deuxième et troisième options utilisent Docker. Cependant, la dernière option fonctionne mieux pour les applications à grande échelle, avec de nombreuses instances Docker exécutées à l'aide de l'option auto-scale. La deuxième option, Cloud Run, convient mieux aux applications de petite et moyenne échelle. Cet article va vous guider dans le processus d'utilisation, de configuration et d'exécution des applications Docker sur GCP (Google Cloud Platform) à l'aide de Cloud Run.

Qu'est-ce que le nuage Google Cloud ?

Google Cloud est un fournisseur de services de Cloud Public. Pour en savoir plus sur GCP, accédez à cette URL (https://googlecloudcheatsheet.withgoogle.com/) :

Il s'agit d'un diagramme interactif. Si vous souhaitez obtenir plus de détails sur le sujet, il vous suffit de cliquer sur une section qui vous intéresse. C'est une façon très divertissante d'en savoir plus.

Obtention d'un exemple d'application Docker à déployer

Nous allons utiliser une application Docker prête du catalogue InterSystems Open Exchange. Pour l'obtenir, suivez les étapes suivantes

1. Assurez-vous que Git est installé.
2. Allez sur https://openexchange.intersystems.com/package/iris-rest-api-template.
3. Clonez/git pull le référentiel dans n'importe quel répertoire local:

git clone git@github.com:intersystems-community/iris-rest-api-template.git

Le modèle iris-rest-api-template est une application backend avec une base de données IRIS et une API REST d'IRIS écrite en ObjectScript. Nous allons déployer cette application sur GCP Cloud Run.

Obtention de vos références AWS

Pour commencer, vous aurez besoin d'un compte GCP et d'un utilisateur disposant d'une clé d'accès. Pour ce faire, procédez comme suit :
Go to https://console.cloud.google.com and enter with an existent user and password or click the link Create account if you don’t have one:

Installation de l'outil gcloud CLI et y affecter l'utilisateur créé

L'outil gcloud CLI est utilisé pour tirer l'image Docker vers AWS ECR (c'est un peu comme le Docker Hub pour les images Docker AWS). Pour l'installer, procédez comme suit :

1. Allez sur https://cloud.google.com/sdk/docs/install et sélectionnez les instructions d'installation adaptées au système d'exploitation de votre ordinateur.

2. Choisissez l'option Run 'gcloud init' :

3. Connectez-vous avec votre utilisateur Google Cloud.
4. Autoriser l'accès à toutes les options requises. Vous êtes maintenant connecté à GCP en utilisant gcloud CLI.
5. À ce stade, choisissez l'option [5] (Créer un nouveau projet) :

6. Saisissez l'ID du projet avec la valeur iriscontainer.

7. Félicitations ! Le projet est créé et prêt à être exploité par CLI.
8. Allez dans le navigateur et choisissez le projet dans le menu déroulant de la console GCP :

9. Passez à l'onglet ALL (tous) et sélectionnez le projet iriscontainer :

10. Choisissez l'option Billing (facturation) dans le menu de gauche :

11. Cliquez sur le bouton LINK A BILLING ACCOUNT (LIER UN COMPTE DE FACTURATION) :

12. Sélectionnez un compte de facturation existant et cliquez sur le bouton SET ACCOUNT (Définir le compte) :

Téléchargement de votre application Docker sur le GCR (Google Container Registry)

1. Allez dans le terminal et activez Docker pour gcloud :

gcloud auth configure-docker

Les résultats de l'exécution sont présentés ci-dessous :

2. Allez au terminal et tapez :

gcloud services <span class="hljs-built_in">enable</span> containerregistry.googleapis.com

3. Maintenant, allez dans votre terminal et trouvez le dossier où vous avez cloné le projet Git (dans mon cas, il s'agit de c:\projetos\isc\iris-rest-api-template) :

4. Créez une balise avant d'envoyer l'image :

5. Exécutez les images Docker pour obtenir le nom de votre image Docker :

 
6. Créer la balise :

7. Envoyer l'image Docker balisée à GCR :

Vous devriez obtenir les résultats d'exécution suivants :
 

À ce stade, votre projet Docker est une image Docker public sur GCR.

Création de l'instance Docker sur GCP Cloud Run pour votre nouvelle image GCR

Puisque votre image Docker est enfin sur GCR, vous pouvez l'utiliser pour lancer une instance. Dans cette section, nous allons créer une instance Docker fonctionnant sur GCP Cloud Run. Pour ce faire, suivez les instructions ci-dessous :

1. Allez dans la console GCP et recherchez Cloud Run dans la barre de recherche supérieure. Cliquez ensuite sur le lien Cloud Run :

2. Cliquez sur le bouton CREATE SERVICE (Créer un service) (en haut ou en bas de page) :

3. Dans Create service (Créer un service), sélectionnez Deploy one revision (déployer une révision) à partir d'une image de conteneur existante.
4. Cliquez sur SELECT (Sélectionner) dans le champ URL de l'image de conteneur :

5. Dans la boîte de dialogue de droite, cliquez sur l'onglet CONTAINER REGISTRY (registre des conteneurs). Après cela, développez le nœud d'arborescence gcr.io/iriscontainer/irissample, choisissez le dernier nœud enfant, et cliquez sur le bouton SELECT (il s'agit de l'image Docker que vous avez téléchargée) :

6. L'URL de l'image du conteneur est maintenant configurée. Cependant, d'autres paramètres sont encore disponibles, faites défiler l'écran pour les voir :
    

7. Appuyez sur la touche Tab pour accéder aux champs Nombre minimum et Nombre maximum d'instances et tapez 1 dans chacun d'eux (cette option nous permettra d'adapter les instances à la charge nécessaire) :

8. Appuyez à nouveau sur la touche Tab ou faites défiler l'écran vers le bas et cochez le bouton "All" ("Tout") (Autoriser l'accès direct à votre service à partir d'Internet). Cette option rendra l'instance disponible sur Internet.
9. Appuyez sur la touche Tab (ou faites défiler l'écran) et sélectionnez Allow unauthenticated invocations (Autoriser les invocations non authentifiées) (cette option est utile pour protéger les ressources avec des références si nécessaire) :

10. Cliquez sur la flèche de développement de la ligne Conteneur, Réseau, Sécurité et cliquez sur la touche Tab, ou faites défiler l'écran vers le bas pour accéder au port du conteneur. Mettez la valeur 52773 (cette option nous permettra d'envoyer les requêtes au port sans exposer ce port à la consommation extérieure) :

11. Appuyez à nouveau sur la touche Tab pour accéder à la rubrique Memory (mémoire) et sélectionnez 4 GiB et CPU 1 (ces options sont très importantes pour la performance car elles définissent le nombre de CPUs et la quantité de mémoire disponible pour l'instance Docker. Cependant, les coûts augmentent également si vous engagez plus de ressources) :

12. Dans l'environnement d'exécution, sélectionnez Défaut :

13. Faites défiler vers le bas ou appuyez sur la touche de tabulation pour atteindre le bouton CREATE. Appuyez ensuite sur ce bouton pour terminer.

14. À ce stade, vous devez attendre quelques instants pour que votre nouvelle demande soit publiée :

15. Vous avez réussi ! Votre application est maintenant disponible :

16. Copiez l'URL de l'application en haut de la page :

17. Ouvrez votre navigateur et tapez ce qui suit (dans mon cas, il s'agit de https://irissample-6bc4etcptq-uc.a.run.app):
    https://irissample-6bc4etcptq-uc.a.run.app/csp/sys/%25CSP.Portal.Home.zen
18. Le portail de gestion IRIS (avec l'utilisateur _SYSTEM et le mot de passe SYS) est désormais actif :

Navigation dans le panneau de service

Vous pouvez contrôler le service déployé. Pour ce faire, suivez les étapes suivantes :

1. Recherchez Cloud Run dans la barre de recherche supérieure et cliquez sur Cloud Run :

2. Cliquez sur le lien irissample pour voir les détails du service :
   

3. Dans l'onglet METRICS, il est possible de voir l'état général du service déployé, y compris la latence, le nombre de requêtes et l'utilisation de la CPU :
    

4. Dans l'onglet LOGS (journaux), vous pouvez voir les journaux de l'application :

  5. Dans l'onglet YAML, vous pouvez vérifier et modifier la configuration du service au format YAML :

Arrêt du service

N'OUBLIEZ PAS D'ARRÊTER LE SERVICE, POUR NE PAS ÊTRE FACTURÉ. Pour ce faire, suivez les instructions suivantes :

1. Recherchez Cloud Run dans la barre de recherche supérieure et cliquez sur Cloud Run :

2. Cochez la case irissample et cliquez sur le bouton DELETE :

P.S. : supprimez également le projet !

GCP et IRIS, l'architecture de référence

Mark Bolinsky, l'architecte principal d'InterSystems, a publié un article présentant les meilleures pratiques et une proposition d'architecture IRIS d'InterSystems pour gérer les projets IRIS essentiels. Pour le consulter, suivez le lien https://community.intersystems.com/post/intersystems-iris-example-reference-architectures-google-cloud-platform-gcp. L'article explore des scénarios de petite, moyenne et grande échelle.

Mes impressions sur GCP

GCP est une option plus facile à utiliser qu'AWS lorsqu'il s'agit de déployer des instances IRIS. Il me semble qu'il s'agit également d'une solution moins onéreuse. D'un autre côté, AWS dispose de ressources et d'options plus avancées en matière de sécurité, de stockage et de services spécialisés tels que l'IA et le WAF. Cependant, il est plus facile de trouver des professionnels qui utilisent AWS, et c'est aussi Cloud Public le plus populaire sur le marché.

Aujourd'hui, la plupart des applications sont déployées sur des services de cloud public. Cela présente de nombreux avantages, notamment des économies de ressources humaines et matérielles, la possibilité de se développer rapidement et à moindre coût, une plus grande disponibilité, une plus grande fiabilité, une évolutivité élastique et des options permettant d'améliorer la protection des actifs numériques. L'une des options les plus populaires est AWS. Nous pouvons y déployer nos applications à l'aide de machines virtuelles (service EC2), de conteneurs Docker (service ECS) ou de Kubernetes (service EKS). La première solution, au lieu d'utiliser Docker, emploie une machine virtuelle avec Windows ou Linux où vous pouvez installer votre serveur et déployer votre application. Cependant, la dernière correspond mieux aux applications à grande échelle avec de nombreuses instances Docker en cours d'exécution grâce à l'option auto-scale. La deuxième solution (ECS), en revanche, est le meilleur choix pour les applications de petite et moyenne échelle.Cet article vous montrera comment utiliser, configurer et exécuter des applications Docker sur AWS à l'aide du service ECS.

Obtention d'un exemple d'application Docker à déployer

Pour notre exemple, nous allons utiliser une application Docker prête du catalogue InterSystems Open Exchange. Pour commencer, suivez les étapes suivantes :

1. Assurez-vous que Git est installé.
2. Allez sur https://openexchange.intersystems.com/package/iris-rest-api-template.
3. Clonez/git pull le référentiel dans n'importe quel répertoire local:

git <span class="hljs-built_in">clone</span> git@github.com:intersystems-community/iris-rest-api-template.git

Le modèle iris-rest-api-template est une application backend avec une base de données IRIS et une API REST d'IRIS écrite en ObjectScript. Nous allons déployer cette application sur le service AWS ECS.

Obtention de vos références AWS

Pour commencer, vous aurez besoin d'un compte AWS et d'un utilisateur disposant d'une clé d'accès. Pour ce faire, procédez comme suit :

1. Allez sur https://aws.amazon.com/console et cliquez sur le bouton de connexion en haut à droite Sign in :

2. Si vous disposez d'un compte AWS, il vous suffit de vous connecter avec celui-ci. Si vous n'en possédez pas, cliquez sur le bouton Create a new AWS account (créer un nouveau compte AWS). Après avoir complété votre profil, connectez-vous avec vos nouvelles données.
3. Dans le champ de recherche supérieur, écrivez IAM ("outil de gestion des identités et des accès AWS"), puis cliquez sur IAM :

4. Dans le menu de gauche, cliquez sur Users (utilisateurs) :

5. Cliquez sur le bouton Add users (ajouter des utilisateurs) :

6. Remplissez le champ qui est apparu avec les valeurs mentionnées ci-dessous :

• Nom d'utilisateur : iris
• Cochez la case Provide user access to the AWS Management Console (fournir un accès à l'utilisateur à la console de gestion AWS).
• Choisissez I want to create an IAM user (Je veux créer un utilisateur IAM)
• Sélectionnez Custom password (mot de passe personnalisé) et saisissez Iris@2023
• Décochez la case Users must create a new password at next sign-in (Les utilisateurs doivent créer un nouveau mot de passe lors de la prochaine connexion)
• Cliquez sur le bouton Next (suivant)

7. Dans les options de permissions, choisissez Attach policies directly (attacher les politiques directement), sélectionnez AdministratorAccess (accès administrateur) et cliquez sur le bouton Next (suivant) :

8. Dans Review and Create, cliquez sur le bouton Create user (créer un utilisateur) dans le pied de page :

9. Cliquez sur le bouton Download .csv file (télécharger le fichier .csv) pour enregistrer les nouvelles références de l'utilisateur.
10. Dans la barre Search de recherche supérieure, recherchez IAM et cliquez sur IAM :

11. Dans le menu de gauche, sélectionnez Users (Utilisateurs) :

12. Cliquez sur le lien de l'utilisateur Iris :

13. Cliquez sur l'onglet Security Credentials (références de sécurité) :

14. Allez dans la sous-section Access keys (clés d'accès) (faites défiler l'écran pour la trouver) et cliquez sur le bouton Create access key (créer une clé d'accès) :

15. Sélectionnez Command Line Interface (interface de ligne de commande), cochez la case "I understand the above recommendation and want to proceed to create an access key" (Je comprends la recommandation ci-dessus et je souhaite procéder à la création d'une clé d'accès), puis cliquez sur le bouton Next (suivant) :

 
16. Cliquez maintenant sur le bouton Create access key (créer une clé d'accès) :

17. Copiez votre clé d'accès et votre clé d'accès secrète dans un fichier sur votre ordinateur. Utilisez le bouton Télécharger le fichier .csv et enfin cliquez sur le bouton Done (terminé) :

Installation de l'outil AWS CLI et y attribuer l'utilisateur créé

L'outil AWS CLI est utilisé pour tirer l'image Docker vers AWS ECR (c'est une sorte de Docker Hub pour les images Docker AWS). Pour l'installer, procédez comme suit :

1. Allez sur https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install... et choisissez les instructions d'installation correspondant au système d'exploitation de votre ordinateur.

2. Après l'installation, si vous ne l'avez pas encore fait, suivez les étapes suivantes :
   a. Sur votre terminal, mettez :
    

aws configure

b. Définissez la clé d'accès créée ci-dessus :

c. Définissez la clé secrète assemblée précédemment :

d. Ne modifiez pas les valeurs restantes. Acceptez simplement les valeurs par défaut :

##  

Téléchargement de votre application Docker sur l'ECR AWS

1. Dans le champ de recherche de la console AWS, recherchez ECR et sélectionnez Elastic Container Registry :

2. Cliquez sur le bouton Get Started (commencer) dans la section Create Repository (créer le référentiel) :

3. Dans Create Repository, mettez les valeurs suivantes :

• Paramètres de visibilité : Public
• Nom du référentiel : iris-repo iris-repo
• Cliquez sur le bouton Create repository (créer le référentiel)

 
4. Le référentiel est maintenant créé. Sélectionnez iris-repo et cliquez sur le bouton View push commands (afficher les commandes push) :

5. Copiez la valeur de l'URI du référentiel (deuxième colonne - URI) et stockez-la dans un fichier. Vous en aurez besoin plus tard au cours de cet article.
6. Exécutez les 4 commandes de la boîte de dialogue dans votre terminal dans le dossier où vous avez cloné le projet Git :

a. Première commande : connectez-vous avec l'utilisateur IRIS :

b. Deuxième commande : docker build -t iris-repo .

 
    
c. Troisième commande : docker tag iris-repo:latest public.ecr.aws/e7i6j8j1/iris-repo:latest

d. Dernière commande : docker push public.ecr.aws/e7i6j8j1/iris-repo:latest

Félicitations ! Votre projet Docker est maintenant une image Docker public sur AWS ECR..

Création de l'instance Docker sur AWS ECS pour votre nouvelle image AWS ECR

Voici venue l'heure des dernières étapes. Nous allons créer une instance Docker fonctionnant sur AWS à ce stade. Pour ce faire, procédez comme suit

1. Accédez à la console AWS et recherchez ECS dans la barre de recherche supérieure. Cliquez ensuite sur le lien Elastic Container Service :

2. Dans le menu de gauche, sélectionnez Clusters :

3. Cliquez sur le bouton Create a cluster (créer un cluster) :

4. Sur Create Cluster, ajoutez la valeur iriscluster au champ Cluster name (nom du cluster). Acceptez les valeurs restantes pour les autres champs et cliquez sur le bouton Create (créer) :

5. Attendez quelques secondes, et vous aurez un nouveau cluster listé :
         

6. Dans le menu de gauche, sélectionnez Task definitions (définitions de tâches) et allez à Create new task definition (créer une nouvelle définition de tâche) :

7. Dans Configure task definition and containers (configuration de la définition de la tâche et des conteneurs), définissez les valeurs indiquées ci-dessous et cliquez sur le bouton Next (suivant) :

• Famille de définition des tâches : iristask
• Détails du conteneur - Nom : irisrepo
• Détails du conteneur - URI de l'image : URI que vous avez stocké dans un fichier lorsque vous avez créé l'image avec ECR. Dans mon cas, il s'agit de public.ecr.aws/e7i6j8j1/iris-repo
• Port de Mappage – Port à conteneurs : 52773, Protocole : TCP.

8. Dans Configure environment, storage, monitoring, and tags (configuration de l'environnement, le stockage, la surveillance et les balises), modifiez la mémoire pour qu'elle soit de 4 Go. Le rôle de la tâche doit être modifié en ecsTaskExecutionRole, et Stockage - Quantité en 30. Pour les autres paramètres, acceptez les valeurs par défaut et cliquez sur le bouton Next (suivant) :

9. Dans Review (révision) and Create (créer), cliquez sur le bouton Create :

10. Cliquez sur le bouton Deploy > Run Task (déployer > exécuter une tâche) en haut de la page :

11. Dans Create (créer), définissez les valeurs mentionnées ci-dessous et cliquez sur le bouton Create :

• Cluster existant : iriscluster
• Options de calcul : Type de lancement Launch
• Type d'application : Task (Tâche)

12. Développez la section Networking (mise en réseau) et choisissez :

• Groupe de sécurité : sélectionnez Create a new security group (créer un nouveau groupe de sécurité)
• Nom du groupe de sécurité : irissec
• Description du groupe de sécurité : irissec
• Règles d'entrée - Type : TCP personnalisé, plage de ports : 52773

13. Attendez un certain temps pour voir l'état de la création (cliquez sur le bouton pour vérifier l'état actuel) :

14. . Lorsque l'état devient "Running" (en cours d'exécution), cliquez sur le lien Task (tâche) :

15. Copiez l'IP public :

16. Ouvrez votre navigateur et tapez (dans mon cas, il s'agit de 54.226.128.138) :
    http://<public ip>:52773/csp/sys/%25CSP.Portal.Home.zen
17. Le portail de gestion IRIS (avec l'utilisateur _SYSTEM et le mot de passe SYS) est maintenant actif, et les services REST pour l'application fonctionnent également (authentification de base avec _SYSTEM et SYS) :

Vous avez réussi ! Vous avez maintenant votre IRIS sur AWS. N'OUBLIEZ PAS D'ARRÊTER LA TÂCHE, POUR NE PAS ÊTRE FACTURÉ. Pour ce faire, cliquez sur le bouton Stop :

 
Profitez-en !

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.

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

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

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

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

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

Scénarios d'architecture et de déploiement

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

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

Revue d'Architecture Caché

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

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

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

Figure 1 : Niveaux de composants de haut niveau

Scénarios de déploiement courants

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

Hybrid Model

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

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

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

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

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

Modèle hébergé dans le cloud

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

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

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

Ressources de stockage et de calcul

Stockage

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

Elastic Block Storage (EBS)

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

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

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

Volumes magnétiques

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

Usage général (SSD)

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

IOPS provisionnés (SSD)

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

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

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

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

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

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

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

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

Calcul

Instances EC2

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

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

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

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

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

Disponibilité et opérations

Équilibrage de la Charge du serveur Web/App

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

Équilibreur de charge Classic Load Balancer

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

Équilibreur de charge Application Load Balancer

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

Exemple

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

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

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

Mise en miroir de base de données

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

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

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

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

Adresse IP virtuelle et basculement automatique

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

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

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

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

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

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

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

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

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

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

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

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

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

Détails de l'API

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

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

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

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

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

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

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

_ /csp/bin/mirror_status.cxw_

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

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

_ /csp/user/mirror_status.cxw_

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

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

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

   HTTP/1.1 200 OK

   Content-Type: text/plain

   Connection: close

   Content-Length: 7

   SUCCESS

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

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

   HTTP/1.1 503 Service Unavailable

   Content-Type: text/plain

   Connection: close

   Content-Length: 6

   FAILED

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

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

   HTTP/1.1 500 Internal Server Error

   Content-Type: text/plain

   Connection: close

   Content-Length: 6

   FAILED

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

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

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

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

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

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

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

Sauvegarde et Restauration

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

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

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

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

Instantanés EBS

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

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

Instantanés de Logical Volume Manager

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

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

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

Caché Online Backup

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

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

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

Reprise après sinistre

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

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

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

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

Les détails de ces fonctions sont disponibles ici.

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

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

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

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

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

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

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

Vérification

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

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

Provisionnement Automatisé

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

Connectivité Réseau

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

Sécurité

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

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

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

Exemples de diagrammes d'architecture

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

Exemple de TrakCare

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

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

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

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

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

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

Exemple de HealthShare

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

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

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

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

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

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

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

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

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

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

Conditions préalables

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

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

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

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

La Configuration du pré-scripting et post-scripting

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

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

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

Et doit être copié aux emplacements suivants respectivement.

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

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

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

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

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

exit $status

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

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

Exécution d'une sauvegarde

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

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

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

Apache Superset est une plate-forme moderne d'exploration et de visualisation des données. Superset peut remplacer ou augmenter les outils de business intelligence propriétaires pour de nombreuses équipes. Superset s'intègre bien à une variété de sources de données.

Désormais, il est également possible de l'utiliser avec InterSystems IRIS.

Une démo en ligne est disponible et elle utilise SQL d'IRIS Cloud comme source de données.

Le support d'IRIS est implémenté avec un paquetage Python nommé superset-iris, qui peut être installé manuellement dans Superset.

Superset utilise SQLAlchemy comme moteur de base de données, tandis que le paquet superset-iris utilise sqlalchemy-iris.

Lorsque le paquet est installé dans l'environnement Superset, il devient possible de sélectionner InterSystems IRIS dans la liste des bases de données prises en charge.

Pour se connecter à la base de données IRIS, il faut un URI SQLAlchemy sous la forme suivante: iris://{login}:{password}@{hostname}:{port}/{namespace}

La connexion de test doit vérifier la disponibilité du serveur. Cliquez ensuite sur Connecter pour terminer l'ajout de la base de données.

Dans le même formulaire d'édition de base de données, dans l'onglet avancé Advanced Tab, et dans le bloc de sécurité Security, l'option nommée Autoriser le téléchargement de fichiers vers la base de données, qui permettra de télécharger des fichiers CSV et de construire des tableaux avec des données dans IRIS en se basant sur ces derniers.

Le Labo SQL, qui permet d'effectuer des requêtes SQL

Il permet également de collecter et d'afficher des renseignements sur les schémas et les tableaux existants, de prévisualiser ces tableaux et de proposer la construction d'une simple requête SQL avec toutes les colonnes.

Pour l'essayer localement, clonez le dépôt

git clone https://github.com/caretdev/superset-iris.git superset-iris
cd superset-iris

Lancez Superset avec Docker-Compose

docker-compose pull
docker-compose up -d

Lancez Superset avec Docker-Compose Pendant le démarrage, il importe les données d'exemple dans la base de données IRIS, cela prendra un certain temps, pour attendre que ce soit fait, exécutez la commande suivante

docker-compose logs -f superset-init

Lorsque la commande ci-dessus a fini de fonctionner, allez à http://localhost:8088/dashboard/list/. Les panneaux de bord sont disponibles sans autorisation. Pour accéder au Labo SQL, utilisez admin/admin comme login et mot de passe.

Veuillez voter sur le concours

De nombreux facteurs influencent la qualité de vie des gens, et l'un des plus importants est le sommeil. La qualité de notre sommeil détermine notre capacité à fonctionner pendant la journée et affecte notre santé mentale et physique. Un sommeil de bonne qualité est essentiel à notre santé et à notre bien-être général. Par conséquent, en analysant les indicateurs précédant le sommeil, nous pouvons déterminer la qualité de notre sommeil. C'est précisément la fonctionnalité de l'application Sheep's Galaxy.

Sheep's Galaxy est un exemple d'application qui fonctionne avec les technologies IntegratedML et IRIS Cloud SQL d'InterSystems et qui fournit à l'utilisateur un outil d'analyse et d'amélioration de la qualité du sommeil. L'analyse du sommeil prend en compte des facteurs tels que les niveaux de bruit, l'éclairage de la pièce, la durée du sommeil, la consommation de caféine, etc., ce qui permet à l'utilisateur de reconsidérer ses habitudes en matière de sommeil et de créer des conditions optimales pour le sommeil à l'avenir.

Présentation vidéo :

https://www.youtube.com/watch?v=eZ9Wak831x4&ab_channel=MariaGladkova

L'application est basée sur les technologies suivantes :

• Angular structure pour le frontend;
• FastApi structure avec un package DB-API pour le backend ;
• IRIS Cloud SQL with IntegratedML pour analyser et stocker des données.

Partie Frontend :

Pour construire cette application, nous avons utilisé la structure Angular. Il nous a aidé à créer une application simple à page unique. Nous avons utilisé Angular v15, et tous les composants Angular ont été implémentés en tant que standalones pour rationaliser l'expérience de création. Nous n'avons pas utilisé de modules Angular et c'est une bonne pratique pour faire évoluer une application dans le futur si nécessaire. Nous avons également utilisé l'architecture des composants intelligents (Smart Component Architecture) - tous les composants de notre application frontale sont divisés en composants "intelligents" et "muets". Ce concept nous aide à séparer le code de logique métier et le code de présentation entre ces composants. Toute la Logique métier et les demandes adressées au serveur sont conservées dans les services isolés. Pour traiter les données de notre backend, nous utilisons RxJS - une bibliothèque pour composer des programmes asynchrones et basés sur des événements en utilisant des séquences observables. Pour styliser notre application, nous avons utilisé Angular Material - il s'agit d'une bibliothèque de composants d'interface utilisateur que les développeurs peuvent utiliser dans leurs projets Angular pour accélérer le développement d'interfaces utilisateur élégantes et cohérentes. Cette bibliothèque offre un grand nombre de composants d'interface utilisateur réutilisables et magnifiques - nous en avons ajouté quelques-uns comme les cartes, les entrées, les tableaux de données, les sélecteurs de date, et bien d'autres encore. Nous présentons ci-dessous une vue d'ensemble du flux de travail typique d'un utilisateur. Tout d'abord, l'utilisateur passe par le processus d'enregistrement, s'il l'utilise pour la première fois, ou par l'écran d'autorisation.

À l'aide de cette application, l'utilisateur entre des renseignements sur son sommeil, tels que son niveau d'activité pendant la journée, le nombre de tasses de café, son confort de sommeil, son niveau de stress et la quantité d'émotions positives, ainsi que la lumière de la pièce et l'heure du coucher.

Après chaque saisie de données, l'utilisateur reçoit une notification sur la qualité de son sommeil. Ces données sont ensuite analysées à l'aide d'algorithmes d'apprentissage automatique afin de fournir aux utilisateurs des informations sur leurs habitudes de sommeil.

Partie Backend :

Fastapi est un framework python basé sur deux technologies : Pydantic et Starlette. Il a les fonctionnalités suivantes :

• Il est basé sur des standards ouverts : OpenAPI, schéma JSON, OAuth2 ;
• Documentation automatique de l'API en swagger ;
• Implémentation des dépendances ;
• Il utilise les fonctionnalités de python moderne : annotation de type, asyncio ;
• Il supporte le code synchrone et asynchrone ;

La structure du projet consiste en des routeurs avec des points d'extrémité, des modèles pour chaque entité et des services de traitement.

Chaque point d'extrémité apparaît dans la documentation atomique à /docs et les champs des points d'extrémité ont une relation avec les modèles de données dans la base de données.

Les modèles pydantiques valident automatiquement les données entrantes et sortantes.

Le processus de traitement des données des utilisateurs repose sur le protocole, qui vous permet de traiter les données en toute sécurité.

Le processus d'interaction avec la base de données est mis en œuvre par la connexion SQL d'IRIS à l'aide de DB API.

IRIS Cloud SQL avec IntegratedML :

Tout d'abord, vous devez vous connecter au portail InterSystems Cloud Services. Vous devez ensuite créer un nouveau déploiement IRIS Cloud SQL. Veillez à inclure IntegratedML lorsque vous créez un nouveau déploiement. Lorsqu'il est prêt, vous pouvez obtenir les paramètres de connexion à utiliser dans docker-compose.yml :

En ouvrant le menu "IntegratedML Tools", vous avez accès à la création, à l'entraînement et à la validation de votre modèle, ainsi qu'à la possibilité de générer des prédictions sur un champ sélectionné dans le tableau de votre modèle.

Dans notre application, nous prédisons la qualité du sommeil sur la base des données de l'utilisateur. Pour ce faire, nous remplissons les champs de la section Prédiction comme suit :

Dans la requête générée, le champ prediction contient une prédiction de la qualité du sommeil, le champ probability_quality (probabilité de qualité) contient la probabilité que le sommeil soit " de bonne qualité ".

Liens :

Pour en savoir plus sur notre projet ou l'utiliser comme modèle pour vos futurs travaux : https://openexchange.intersystems.com/package/Sheep%E2%80%99s-Galaxy

Remerciements :

Notre équipe tient à remercier InterSystems et Banksia Global de nous avoir donné l'occasion de travailler avec une technologie de pointe sur des questions importantes.

Développeurs du projet :

• Maria Gladkova
• Katsiaryna Shaustruk
• Maria Nesterenko

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

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

Conditions préalables

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

Démarrage

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

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

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

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

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

• Étape 5 : Exploration du tableau de bord explicatif

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

Commençons donc par la première étape

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

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

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

Connectez-vous au portail InterSystems Cloud Service Portal

Sélectionner le déploiement en cours

Étape 2.1 : Ajout et gestion des fichiers

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

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

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

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

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

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

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

###

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

###

Importez des fichiers de données

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

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

###

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

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

Assurez-vous que 4000 lignes sont mises à jour

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

Étape 2.3 : Création du modèle

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

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

Étape 2.4 : Entraînement du modèle

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

###

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

###

Étape 2.5 : Validation du modèle

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

###

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

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

Étape 3 : Activation de l'environnement virtuel Python

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

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

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

Pour Windows:

venv\scripts\activate

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

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

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

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

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

python app.py

###

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

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

Étape 5 : Exploration du tableau de bord explicatif

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

python expdash.py

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

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

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

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

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

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

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

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

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

Merci

InterSystems Kubernetes Operator (IKO) 3.5 est désormais généralement disponible. IKO 3.5 ajoute de nouvelles fonctionnalités importantes ainsi que de nombreuses corrections de bogues. Les faits saillants comprennent :

Salut les développeurs,

Nous aimerions vous inviter à participer à notre prochain concours dédié à la création des solutions d'IA/ML qui utilisent Cloud SQL pour travailler avec les données :

🏆 Concours InterSystems IRIS Cloud SQL et IntegratedML 🏆

Durée: du 3 avril au 23 avril 2023

Prix: $13,500!

La fonction en tant que service (FaaS) est une catégorie de services de cloud computing qui fournit une plate-forme permettant aux clients de développer, d'exécuter et de gérer des fonctionnalités d'application sans la complexité de la construction et de la maintenance de l'infrastructure généralement associée au développement et au lancement d'une application. Construire une application selon ce modèle est une façon de réaliser une architecture "sans serveur", et est généralement utilisé lors de la construction d'applications microservices.  

Wikipedia

FaaS est une approche extrêmement populaire pour exécuter des charges de travail dans le cloud, permettant aux développeurs de se concentrer sur l'écriture du code.

Cet article vous montrera comment déployer les méthodes d'InterSystems IRIS selon l'approche FaaS.

Installation de Kubernetes

Tout d'abord, installez Kubernetes 1.16. Il y a beaucoup de guides disponibles donc je ne vais pas les copier ici, mais j'utilise minicube. Avec minicube pour lancer kubernetes, il suffit d'exécuter la commande suivante :

minikube start --kubernetes-version=v1.16.1

Installation de kubeless

Ensuite, nous allons installer kubeless. kubeless est un environnement sans serveur natif de Kubernetes qui vous permet de déployer de petits morceaux de code sans vous soucier de la plomberie de l'infrastructure sous-jacente. Il exploite les ressources de Kubernetes pour fournir une mise à l'échelle automatique, un routage API, une surveillance, un dépannage, etc.

kubectl create ns kubeless
kubectl create -f https://github.com/kubeless/kubeless/releases/download/v1.0.8/kubeless-v1.0.8.yaml
kubectl get pods -n kubeless

La sortie devrait ressembler à ceci :

NAME READY STATUS RESTARTS AGE kubeless-controller-manager-666ffb749-26vhh 3/3 Running 0 83s

Vous devez également installer un client kubeless (sur la même instance que celle où vous avez kubectl). Vous pouvez l'obtenir ici. L'installation sur Linux est aussi simple :

sudo install kubeless /usr/local/bin/kubeless

Test kubeless

Tout d'abord, déployons une simple fonction Python pour vérifier le fonctionnement de kubeless.

Create test.py:

def hello(event, context):
  return event['data']

Pour en savoir plus sur l'environnement des fonctions, consultez cette documentation. En général, les fonctions acceptent deux arguments - l'événement et le contexte avec les données suivantes :

event:                                  
data:                                         # Event data
foo: "bar"                                  # The data is parsed as JSON when required
event-id: "2ebb072eb24264f55b3fff"            # Event ID
event-type: "application/json"                # Event content type
event-time: "2009-11-10 23:00:00 +0000 UTC"   # Timestamp of the event source
event-namespace: "kafkatriggers.kubeless.io"  # Event emitter
extensions:                                   # Optional parameters
request: ...                                # Reference to the request received 
response: ...                               # Reference to the response to send 
                                            # (specific properties will depend on the function language)
context:
function-name: "pubsub-nodejs"
timeout: "180"
runtime: "nodejs6"
memory-limit: "128M"

   Maintenant nous pouvons déployer notre fonction hello en spécifiant notre fichier avec une fonction et un runtime :

kubeless function deploy hello --runtime python3.7 --from-file test.py --handler test.hello
kubeless function ls hello

Et testons-les :

kubeless function call hello --data 'Hello world!'

Vous devriez recevoir Hello World! comme réponse.

Ajout de la configuration IRIS

Ensuite, nous devons ajouter un gestionnaire de fonction IRIS d'InterSystems, pour ce faire, ouvrez la configuration de kubeless pour modifier :

kubeless get-server-config
kubectl get -n kubeless configmaps -o yaml > configmaps.yaml
kubectl edit -n kubeless configmaps

Ajoutez cette entrée au tableau runtime-images et enregistrez :

{"ID": "iris","depName": "","fileNameSuffix": ".cls","versions": [{"images": [{"image": "eduard93/kubeless-iris-runtime:latest","phase": "runtime"}],"name": "iris2022.1","version": "2022.1"}]}

Relancez le contrôleur kubeless pour que les changements prennent effet.

kubectl delete pod -n kubeless -l kubeless=controller

Construction et publication de la fonction IRIS CRD

Maintenant, écrivons notre première fonction dans IRIS d'InterSystems :

Class User.Test {

ClassMethod hi(event, context) As %Status
{
    if $isObject(event) {
        write event.Text + event.Text
    } else {
        write "HELLO FROM IRIS"
    }
    quit $$$OK
}
}

Ensuite, nous devons construire une fonction CRD :

Voici notre modèle :

apiVersion: kubeless.io/v1beta1
kind: Function
metadata:
  name: !name!
  namespace: default
spec:
  runtime: iris2022.1
  timeout: "180"
  handler: !handler!
  deps: ""
  function-content-type: text
  deployment:
    spec:
      template:
        spec:
          securityContext:
            runAsUser: 51773
            runAsGroup: 51773
  function: |

Nous avons besoin de remplir le suivant :

• name : nom de la fonction (pour kubeless)
  • handler : class.name_method (pour InterSystems IRIS)
  • function body : ajouter à la fin (n'oubliez pas les tabulations !)

apiVersion: kubeless.io/v1beta1
kind: Function
metadata:
  name: iris-demo
  namespace: default
spec:
  runtime: iris2022.1
  timeout: "180"
  handler: User_Test.hi
  deps: ""
  function-content-type: text
  deployment:
    spec:
      template:
        spec:
          securityContext:
            runAsUser: 51773
            runAsGroup: 51773
  function: |
    Class User.Test {
ClassMethod hi(event, context) As %Status
{
    if $isObject(event) {
        write event.Text + event.Text
    } else {
        write "HELLO FROM IRIS"
    }
    quit $$$OK
}
}</pre>

Ceci peut être facilement automatisé. Sous Linux, exécutez :

sed 's/!name!/iris-demo/; s/!handler!/User_Test.hi/' function.yaml > function_demo.yaml
sed  's/^/     /'  User.Test.cls >> function_demo.yaml

Et sous Windows (PowerShell):

Get-Content function.yaml | ForEach-Object { $_ -replace "!handler!", "User_Test.hi" -replace "!name!", "iris-demo" } | Set-Content function_demo.yaml
"    " + [string]((Get-Content User.Test.cls)  -join "`r`n    ") | Add-Content function_demo.yaml

Maintenant nous devons publier notre CRD dans kubeless :

kubectl apply -f function_demo.yaml

Test de la fonction IRIS

Tout d'abord, vérifions que la fonction est déployée et disponible ( la première fois, cela peut prendre quelques minutes) :

kubeless function ls

Et maintenant, faites un appel :

kubeless function call iris-demo --data '{"Text":123}'

Si vous êtes sous Windows, appelez la fonction comme ceci (de même pour tous les autres appels avec des guillemets échappés) :

kubeless function call iris-demo --data '{\"Text\":123}'

De toute façon, la réponse devrait être 456 puisque 123 est un numéro.

L'accès HTTP

kubeless offre également un accès HTTP. Pour le tester, utilisez la commande kubectl proxy :

kubectl proxy -p 8081

Ensuite, envoyez cette requête en utilisant votre client API REST préféré :

GET http://localhost:8081/api/v1/namespaces/default/services/iris-demo:http-function-port/proxy/

{"Text":111}

Voici comment cela se présente dans Postman :

Ensuite, il s'agit de le publier sur l'internet.

Il y a deux approches. Il est préférable de configurer ingress comme décrit ici.

En outre, vous pouvez patcher le service de fonction :

kubectl get svc
kubectl patch svc iris-demo -p '{"spec": {"type": "LoadBalancer"}}'
kubectl get svc

Nettoyage

Pour supprimer une fonction déployée, faites un appel :

kubectl delete -f function_demo.yaml

Conclusion

Bien qu'il s'agisse sans aucun doute d'une preuve de concept et non d'une solution de production, cette approche démontre qu'il est possible d'exécuter des charges de travail IRIS d'InterSystems en utilisant l'approche FaaS sans serveur.

Liens

• Minicube
• Kubeless
• InterSystems IRIS runtime

Bonjour la communauté,

Nous sommes heureux d'annoncer que InterSystems IRIS, IRIS for Health, HealthShare Health Connect et InterSystems IRIS Studio 2022.2 sont maintenant disponibles !

Et pour discuter de toutes les fonctionnalités nouvelles et améliorées de celui-ci, nous aimerions vous inviter à notre webinaire Quoi de neuf dans InterSystems IRIS 2022.2.

Est-ce que vous souhaitez inclure une implémentation FHIR® de qualité commerciale dans votre écosystème de micro-services et vous avez à peine le temps de remplir les formulaires de sélection de votre régime d'assurance maladie ?

Voici un moyen rapide d'inviter le service InterSystems® FHIR®Accelerator à votre groupe de microservices Kubernetes pour une utilisation immédiate. La solution fait appel à des mouvements de proxy ninja de Nginx pour faire le travail. Bien qu'il s'agisse d'une solution rustique qui ne manquera pas de susciter des débats techniques, je suis plutôt satisfait des résultats obtenus, et ce jusqu'à ce que la communauté me dise le contraire, alors, comme on dit, " FHIR® ", mais ce serait formidable si vous m'écoutiez d'abord.

Clause de non-responsabilité

Vous verrez des secrets dans les manifestes, l'utilisation des port de nœuds nodePort et un nœud maître corrompu pour faire passer le message, la discrétion parentale est conseillée.

Préalables

Vous aurez besoin de quelques éléments si vous souhaitez le déployer vous-même. Il s'agit principalement d'un point de départ ou d'une approche pour ceux qui souhaitent intégrer rapidement la fonctionnalité FHIR® à des fins de développement.

🔥 Environnement

Pour cette démonstration, nous sommes parqués directement sur un nœud maître de Kubernetes corrompu pour mettre en œuvre le travail.

FHIR up le service FHIR® Accelerator

• [X ] Créez un compte dans l'InterSystems® Cloud
• [ X] Créez un déploiement de service InterSystems FHIR® Accelerator

• Créez une clé Api

🖇 Enregistrez le point de terminaison et la clé API

C'est tout ce que nous avons besoin de l'accélérateur FHIR®, nous interagirons avec le service à notre manière à l'intérieur du cluster Kubernetes.

Clonage de ce Repo

Pour le "reste du README", placez-vous sur un nœud maître Kubernetes corrompu.

git clone https://gitlab.com/isc_cloud/fhiraas-microservice-kubernetes.git
cd fhir-microservice-kubernetes

Déploiement vers le cluster Kubernetes

• [X ] Créez un espace de nom Namespace, afin de disposer d'un rayon d'explosion dans lequel jouer pour l'instant.
• Creez une ConfigMap, il s'agit en fait de la folie du reverse proxy implémentée dans le nginx.conf.

✏ IL FAUT MODIFIER QUELQUE CHOSE ICI

Rappelez-vous la clé et le point de terminaison que nous avons générés à partir du service FHIR Accelerator ? Il faut les mettre à jour ici, dans le déploiement

• [ X] Créez un déploiement, voici les conteneurs eux-mêmes, avec 3 modules pour le groupe de répliques de déploiement.
• [ X] Créez un Service, Exposez-le !, c'est un simple service NodePort qui lie un port sur le nœud pour accéder au service FHIR Accelerator. Il expose 30036 sur le nœud, et transmet au module de déploiement sur 52773.

cd fhir-microservice-kubernetes # devrait déjà être ici, mais juste pour être sûr.
kubectl apply -f k8s/

Testez-le !

Faisons un test rapide pour vérifier si FHIR est bien servi à travers le NodePort.

[✔] Port du noeud Socket en écoute ? [✔] Écouter le port du noeud Socket ? [✔] Consultation des patients ?
[✔] Obtenez le patient ?

Mettre à l'échelle !

Nous sommes sur un seul nœud et exposons le service à un port de nœud, donc nous ne sommes pas sûrs que cela augmentera notre débit, mais allons-y quand même.

kubectl scale deployments/isc-fhiraas-deployment --replicas=30 -n isc-fhiraas

Mettons-y un peu de FHIR !

Ce dépôt contient un script shell hostile et rustique qui permet de placer des patients aléatoires dans la ressource Patient, avec quelques cloches et sans sifflets. J'ai besoin de quelques variables d'environnement ou vous pouvez simplement éditer les variables directement dans le script. Lors de l'exécution de ce script, assurez-vous du bon fonctionnement du ventilateur du processeur et déplacez les objets de la zone de l'ordinateur portable pour éviter le déplacement des objets dans le cas où votre ordinateur portable s'envole.

bash bin/fhirbench.sh

🏆 Résultats

50 placements, et 50 recherches en 13 secondes.

Personne responsable

Ce matériel se trouve dans le référentiel, Ron Sweeney (ron.sweeney@integrationrequired.com) de [Intégration requise] (https://www.integrationrequired.com). Ce sont les opinions de mon employeur.

IRIS External Table est un projet Open Source de la communauté InterSystems, qui vous permet d'utiliser des fichiers stockés dans le système de fichiers local et le stockage d'objets en nuage comme AWS S3, en tant que tables SQL.

Il peut être trouvé sur Github https://github.com/intersystems-community/IRIS-ExternalTable Open Exchange https://openexchange.intersystems.com/package/IRIS-External-Table et est inclus dans InterSystems Package Manager ZPM.

Pour installer External Table depuis GitHub, utilisez :

git clone https://github.com/antonum/IRIS-ExternalTable.git
iris session iris
USER>set sc = ##class(%SYSTEM.OBJ).LoadDir("<path-to>/IRIS-ExternalTable/src", "ck",,1)

Pour installer avec ZPM Package Manager, utilisez :

USER>zpm "install external-table"

Travailler avec des fichiers locaux

Créons un fichier simple qui ressemble à ceci :

a1,b1
a2,b2

Ouvrez votre éditeur préféré et créez le fichier ou utilisez simplement une ligne de commande sous linux/mac :

echo $'a1,b1\na2,b2' > /tmp/test.txt

Dans IRIS SQL, créez une table pour représenter ce fichier :

create table test (col1 char(10),col2 char(10))

Convertissez la table pour utiliser le stockage externe :

CALL EXT.ConvertToExternal(
    'test',
    '{
        "adapter":"EXT.LocalFile",
        "location":"/tmp/test.txt",
        "delimiter": ","
    }')

Et enfin - interrogez la table :

select * from test

Si tout fonctionne comme prévu, vous devriez voir un résultat comme celui-ci :

col1	col2
a1	b1
a2	b2

Retournez maintenant dans l'éditeur, modifiez le contenu du fichier et réexécutez la requête SQL. Ta-Da !!! Vous lisez les nouvelles valeurs de votre fichier local en SQL.

col1	col2
a1	b1
a2	b99

Lecture de données à partir de S3

Sur <https://covid19-lake.s3.amazonaws.com/index.html >, vous pouvez avoir accès à des données constamment mises à jour sur le COVID, stockées par AWS dans la réserve publique de données.

Essayons d'accéder à l'une des sources de données de cette réserve de données : s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states

Si vous avez installé l'outil de ligne de commande AWS, vous pouvez répéter les étapes ci-dessous. Sinon, passez directement à la partie SQL. Vous n'avez pas besoin d'installer quoi que ce soit de spécifique à AWS sur votre machine pour suivre la partie SQL.

$ aws s3 ls s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/
2020-12-04 17:19:10     510572 us-states.csv

$ aws s3 cp s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/us-states.csv .
download: s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/us-states.csv to ./us-states.csv

$ head us-states.csv
date,state,fips,cases,deaths
2020-01-21,Washington,53,1,0
2020-01-22,Washington,53,1,0
2020-01-23,Washington,53,1,0
2020-01-24,Illinois,17,1,0
2020-01-24,Washington,53,1,0
2020-01-25,California,06,1,0
2020-01-25,Illinois,17,1,0
2020-01-25,Washington,53,1,0
2020-01-26,Arizona,04,1,0

Nous avons donc un fichier avec une structure assez simple. Cinq champs délimités.

Pour exposer ce dossier S3 en tant que table externe - d'abord, nous devons créer une table "normal" avec la structure désirée :

-- create external table
create table covid_by_state (
    "date" DATE,
    "state" VARCHAR(20),
    fips INT,
    cases INT,
    deaths INT
)


Notez que certains noms de champs comme "Date" sont des mots réservés dans IRIS SQL et doivent être entourés de guillemets doubles.
Ensuite - nous devons convertir cette table "régulière" en table "externe", basé sur le godet AWS S3 et le type de CSV.

 -- convertissez le tableau en stockage externe
call EXT.ConvertToExternal(
    'covid_by_state',
    '{
    "adapter":"EXT.AWSS3",
    "location":"s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/",
    "type": "csv",
    "delimiter": ",",
    "skipHeaders": 1
    }'
)

Si vous regardez de près - les arguments des procédures EXT.ExternalTable sont le nom de la table et ensuite une chaîne JSON, contenant plusieurs paramètres, tels que l'emplacement pour rechercher les fichiers, l'adaptateur à utiliser, le délimiteur, etc. En plus de AWS S3 External Table supporte le stockage Azure BLOB, Google Cloud Buckets et le système de fichiers local. GitHub Repo contient des références pour la syntaxe et les options supportées pour tous les formats.

Et enfin - faites une requête sur le tableau :

-- faites une requête sur le tableau :
select top 10 * from covid_by_state order by "date" desc

[SQL]USER>>select top 10 * from covid_by_state order by "date" desc
2.	select top 10 * from covid_by_state order by "date" desc

date	état	fips	cas	morts
2020-12-06	Alabama	01	269877	3889
2020-12-06	Alaska	02	36847	136
2020-12-06	Arizona	04	364276	6950
2020-12-06	Arkansas	05	170924	2660
2020-12-06	California	06	1371940	19937
2020-12-06	Colorado	08	262460	3437
2020-12-06	Connecticut	09	127715	5146
2020-12-06	Delaware	10	39912	793
2020-12-06	District of Columbia	11	23136	697
2020-12-06	Florida	12	1058066	19176

L'interrogation des données de la tableau distant prend naturellement plus de temps que celle de la table "IRIS natif" ou global, mais ces données sont entièrement stockées et mises à jour sur le nuage et sont introduites dans IRIS en coulisse.

Explorons quelques autres caractéristiques de la table externe.

%PATH et tables, sur la base de plusieurs fichiers

Dans notre exemple, le dossier du godet ne contient qu'un seul fichier. Le plus souvent, il contient plusieurs fichiers de la même structure, où le nom de fichier identifie soit l'horodatage, soit le numéro de périphérique, soit un autre attribut que nous voulons utiliser dans nos requêtes.

Le champ %PATH est automatiquement ajouté à chaque table externe et contient le chemin d'accès complet au fichier à partir duquel la ligne a été récupérée.

select top 5 %PATH, * from covid_by_state

%PATH	date	state	fips	cases	deaths
s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/us-states.csv	2020-01-21	Washington	53	1	0
s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/us-states.csv	2020-01-22	Washington	53	1	0
s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/us-states.csv	2020-01-23	Washington	53	1	0
s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/us-states.csv	2020-01-24	Illinois	17	1	0
s3://covid19-lake/rearc-covid-19-nyt-data-in-usa/csv/us-states/us-states.csv	2020-01-24	Washington	53	1	0

Vous pouvez utiliser ce champ %PATH dans vos requêtes SQL comme n'importe quel autre champ.

Données ETL vers des " tables réguliers "

Si votre tâche consiste à charger des données de S3 dans une table IRIS - vous pouvez utiliser l'External Table comme un outil ETL. Il suffit de le faire :

INSERT INTO internal_table SELECT * FROM external_table

Dans notre cas, si nous voulons copier les données COVID de S3 dans la table local :

--create local table
create table covid_by_state_local (
    "date" DATE,
    "state" VARCHAR(100),
    fips INT,
    cases INT,
    deaths INT
)
--ETL from External to Local table
INSERT INTO covid_by_state_local SELECT TO_DATE("date",'YYYY-MM-DD'),state,fips,cases,deaths FROM covid_by_state

JOIN entre IRIS tables natif et External Table. Requêtes fédérées

External Table est une table SQL. Il peut être joint à d'autres tables, utilisé dans des sous-sélections et des UNIONs. Vous pouvez même combiner la table IRIS "Régulier" et deux ou plusieurs tables externes provenant de sources différentes dans la même requête SQL.

Essayez de créer une table régulier, par exemple en faisant correspondre les noms d'État aux codes d'État, comme Washington - WA. Et joignez-la à notre table basé sur S3.

create table state_codes (name varchar(100), code char(2))
insert into state_codes values ('Washington','WA')
insert into state_codes values ('Illinois','IL')

select top 10 "date", state, code, cases from covid_by_state join state_codes on state=name

Remplacez 'join' par 'left join' pour inclure les lignes pour lesquelles le code d'état n'est pas défini. Comme vous pouvez le constater, le résultat est une combinaison de données provenant de S3 et de votre table IRIS natif.

Accès sécurisé aux données

La réserve de données AWS Covid est publique. N'importe qui peut y lire des données sans aucune authentification ou autorisation. Dans la vie réelle, vous souhaitez accéder à vos données de manière sécurisée, afin d'empêcher les étrangers de jeter un coup d'œil à vos fichiers. Les détails complets de la gestion des identités et des accès (IAM) d'AWS n'entrent pas dans le cadre de cet article. Mais le minimum, vous devez savoir que vous avez besoin au moins de la clé d'accès au compte AWS et du secret afin d'accéder aux données privées de votre compte. <https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys >

AWS utilise l'authentification par clé de compte/secrète autentification pour signer les demandes. https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys

Si vous exécutez IRIS External Table sur une instance EC2, la méthode recommandée pour gérer l'authentification est d'utiliser les rôles d'instance EC2 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html IRIS External Table sera en mesure d'utiliser les permissions de ce rôle. Aucune configuration supplémentaire n'est requise.

Sur une instance locale/non EC2, vous devez spécifier AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY en spécifiant des variables d'environnement ou en installant et en configurant le client AWS CLI.

export AWS_ACCESS_KEY_ID=AKIAEXAMPLEKEY
export AWS_SECRET_ACCESS_KEY=111222333abcdefghigklmnopqrst

Assurez-vous que la variable d'environnement est visible dans votre processus IRIS. Vous pouvez le vérifier en exécutant :

USER>write $system.Util.GetEnviron("AWS_ACCESS_KEY_ID")

Il doit renvoi la valeur de clé.

ou installer AWS CLI, en suivant les instructions ici https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-linux.html et exécuter :

aws configure

External Table sera alors en mesure de lire les informations d'identification à partir des fichiers de configuration aws cli. Votre shell interactif et votre processus IRIS peuvent être exécutés sous différents comptes - assurez-vous d'exécuter aws configure sous le même compte que votre processus IRIS.