#Red Hat Enterprise Linux (RHEL)

InterSystems a le plaisir d'annoncer que les produits suivants sont désormais disponibles pour Red Hat Enterprise Linux 10 :

• InterSystems IRIS Data Platform 2025.1.0.230.2
• InterSystems IRIS for Health 2025.1.0.230.2
• HealthShare Health Connect 2025.1.0.230.2

Cette version prend désormais en charge le système d'exploitation Red Hat Enterprise Linux 10. RHEL 10 inclut le noyau Linux 6.12.0, des améliorations de sécurité, des optimisations de performances et des outils de développement améliorés.

Comment obtenir le logiciel ?

InterSystems a travaillé en étroite collaboration avec l'équipe Red Hat Insights pour mettre en œuvre un ensemble de recommandations destinées aux administrateurs de systèmes afin de garantir une expérience optimale de l'utilisation d'InterSystems IRIS sur Red Hat Enterprise Linux (RHEL). Inclus dans tous les abonnements RHEL, le service Insights identifie de façon proactive les problèmes potentiels des plateformes et applications surveillées fonctionnant sur RHEL. Grâce à notre collaboration conjointe, le service Insights surveille désormais les scénarios courants qui diminuent les performances de l'IRIS dans la plupart des cas et propose une recommandation approuvée par InterSystems à prendre en compte.  

Dix recommandations sont actuellement mises en œuvre et peuvent être trouvées sous le titre "InterSystems" dans le service Insights Advisor.  Les recommandations d'Advisor apportent une aide dans les domaines suivants:

1. Guide d'optimisation des performances. Nous fournissons les meilleures pratiques pour configurer les HugePages, les Transparent HugePages (THP), le swappiness, les paramètres du noyau shmmax, et plus encore.
2. Compatibilité des produits. Compatibilité des produits. Le service Insights met en évidence les versions des produits InterSystems dont l'utilisation est encouragée afin d'offrir la meilleure expérience possible.
3. Journalisation et suggestions de configuration de haute disponibilité, comme le mappage des lecteurs de Write Image Journaling (WIJ), l'identification d'un arbitre pour prendre en charge la défaillance automatique, ou l'activation de FreezeOnError pour améliorer l'intégrité et la capacité de récupération de la base de données InterSystems IRIS.

Chaque recommandation contient des détails sur la version RHEL détectée, des informations sur l'instance IRIS d'InterSystems et des instructions étape par étape spécifiques au système pour remédier au problème détecté.  Des liens vers la documentation d'InterSystems sont également fournis à titre de référence.

Activation immédiate d'Insights avec InterSystems.

L'enregistrement de vos systèmes avec Red Hat Insights est très simple et ne nécessite généralement que l'exécution d'une seule commande. Alternativement, l'application de l'assistant d'enregistrement de Red Hat peut être utilisée pour compléter les étapes nécessaires en fonction de votre configuration. L'analyse des charges de travail d'InterSystems IRIS ne nécessite pas d'étapes supplémentaires et est activée une fois que les systèmes sont enregistrés dans Insights. Des recommandations spécifiques peuvent être facilement désactivées si elles ne s'appliquent pas à votre environnement.  

Rendez-vous sur Red Hat Insights pour en savoir plus sur le service et commencer à utiliser l'assistant d'enregistrement.

Discutez avec les experts de Red Hat lors de l'InterSystems Global Summit 2024.

Red Hat sera présent à sommet mondial InterSystems Global Summit du 9 au 12 juin et sera disponible pour discuter d'Insights et d'autres fonctionnalités de Red Hat.

Pour votre commodité, InterSystems publie les étapes d'installation typiques pour les systèmes d'exploitation pris en charge par InterSystems IRIS.

Pour Microsoft Windows, veuillez consulter la documentation.

Le programme d'installation d'IRIS détectera si un serveur Web est installé sur la même machine, ce qui vous donne la possibilité de configurer automatiquement le serveur Web.

Toutes les installations Apache nécessiteront une autorisation sudo (recommandé) ou root pour installer le serveur Web. Cette exigence prend en charge les meilleures pratiques recommandées.

Alertes Red Hat Insights désormais disponibles pour InterSystems IRIS

InterSystems et Red Hat travaillent ensemble pour ajouter des alertes spécifiques à IRIS à Red Hat Insights.

Red Hat Insights est un service permettant de prédire et de recommander des mesures correctives pour les risques système dans les environnements Red Hat Enterprise Linux. Insights est gratuit avec presque tous les abonnements RHEL, OpenShift ou Ansible. Vous pouvez savoir plus sur Insights sur le site de Red Hat.

Recommandation swappiness

Il y a souvent des questions concernant la configuration idéale du Serveur Web HTTPD Apache pour HealthShare.  Le contenu de cet article décrit la configuration initiale recommandée du serveur Web pour tout produit HealthShare. 

APour commencer, la version 2.4.x (64 bits) d'Apache HTTPD est recommandée.  Des versions antérieures comme 2.2.x sont disponibles, mais la version 2.2 n'est pas recommandée pour les performances et l'évolutivité de HealthShare.

Configuration d'Apache

Module API Apache sans NSD {#ApacheWebServer-ApacheAPIModulewithoutNSD}

HealthShare requiert l'option d'installation Apache API Module without NSD. La version des modules liés dynamiquement dépend de la version d'Apache :

• CSPa24.so (Apache Version 2.4.x)

La configuration de Caché Server Pages dans le fichier Apache httpd.conf doit être effectuée par l'installation de HealthShare qui est détaillée plus loin dans ce document. Cependant, la configuration peut être effectuée manuellement. Pour plus d'informations, veuillez consulter le guide de configuration d'Apache dans la documentation d'InterSystems : Recommended Option: Apache API Module without NSD (CSPa24.so)

Recommandations concernant le module multiprocesseur d'Apache (MPM) {#ApacheWebServer-ApacheMulti-ProcessingModule(MPM)Recommendations}

Apache Prefork MPM Vs. Worker MPM {#ApacheWebServer-ApachePreforkMPMVs.WorkerMPM}

Le serveur web HTTPD Apache est livré avec trois modules multiprocesseurs (MPM) : Prefork, Worker et Event.  Les MPM sont responsables de la liaison avec les ports réseau de la machine, de l'acceptation des requêtes et de l'envoi de fils pour traiter ces requêtes. Par défaut, Apache est généralement configuré avec le MPM Prefork, qui n'est pas adapté à des charges de travail importantes en termes de transactions ou d'utilisateurs simultanés.

Pour les systèmes de production HealthShare, le MPM Apache Worker doit être activé pour des raisons de performance et d'évolutivité. Worker MPM est préféré pour les raisons suivantes :

• Prefork MPM utilise plusieurs processus enfants avec un fil d'exécution chacun et chaque processus gère une connexion à la fois. Lorsque Prefork est utilisé, les demandes simultanées souffrent car, comme chaque processus ne peut traiter qu'une seule demande à la fois, les demandes sont mises en attente jusqu'à ce qu'un processus serveur se libère. De plus, afin d'évoluer, il faut plus de processus enfants Prefork, ce qui consomme des quantités importantes de mémoire.
• Worker MPM utilise plusieurs processus enfants avec de nombreux fils d'exécution chacun. Chaque fil d'exécution gère une connexion à la fois, ce qui favorise la concurrence et réduit les besoins en mémoire. Worker gère mieux la concurrence que Prefork, car il y aura généralement des fils d'exécution libres disponibles pour répondre aux demandes au lieu des processus Prefork à un seul fil d'exécution qui peuvent être occupés.

Paramètres MPM pour Apache Worker {#ApacheWebServer-ApacheWorkerMPMParameters}

En utilisant des fils d'exécution pour servir les demandes, Worker est capable de servir un grand nombre de demandes avec moins de ressources système que le serveur basé sur le processus Prefork. 
Les directives les plus importantes utilisées pour contrôler le MPM de Worker sont ThreadsPerChild qui contrôle le nombre de fils d'exécution déployés par chaque processus enfant et MaxRequestWorkers qui contrôle le nombre total maximum de fils d'exécution pouvant être lancés.
Les valeurs recommandées de la directive commune Worker MPM sont détaillées dans le tableau ci-dessous :

<th>
  Valeur recommandée
</th>

<th>
  Commentaires
</th>

<td>
  Nombre maximal d'utilisateurs simultanés de HealthShare Clinical Viewer, ou des quatre autres composants de HealthShare, fixé à la somme de toutes les tailles de pool de services commerciaux entrants pour toutes les productions d'interfaces définies. * Note : Si toutes les inconnues au moment de la configuration commencent par une valeur de '1000'
</td>

<td>
    MaxRequestWorkers fixe la limite du nombre de demandes simultanées qui seront servies, c'est-à-dire qu'il restreint le nombre total de fils d'exécution qui seront disponibles pour servir les clients. Il est important que MaxRequestWorkers soit défini correctement car s'il est trop faible, les ressources seront gaspillées et s'il est trop élevé, les performances du serveur seront affectées. Notez que lorsque le nombre de connexions tentées est supérieur au nombre de travailleurs, les connexions sont placées dans une file d'attente. La file d'attente par défaut peut être ajustée avec la directive ListenBackLog.  
</td>

<td>
  250
</td>

<td>
    MaxSpareThreads traite les threads inactifs à l'échelle du serveur. S'il y a trop de threads inactifs dans le serveur, les processus enfants sont tués jusqu'à ce que le nombre de threads inactifs soit inférieur à ce nombre. L'augmentation du nombre de threads inutilisés par rapport à la valeur par défaut permet de réduire les risques de réactivation des processus.  
</td>

<td>
  75
</td>

<td>
    MinSpareThreads traite les fils d'exécution inactifs à l'échelle du serveur. S'il n'y a pas assez de fils d'exécution libres dans le serveur, des processus enfants sont créés jusqu'à ce que le nombre de fils d'exécution libres soit supérieur à ce nombre. En réduisant le nombre de fils d'exécution inutilisés par rapport à la valeur par défaut, on réduit les risques de réactivation des processus.  
</td>

<td>
  MaxRequestWorkers divisé par ThreadsPerChild
</td>

<td>
    Valeur maximale de MaxRequestWorkers pour la durée de vie du serveur. ServerLimit est une limite stricte du nombre de processus enfants actifs, et doit être supérieure ou égale à la directive MaxRequestWorkers divisée par la directive ThreadsPerChild. Avec worker, n'utilisez cette directive que si vos paramètres MaxRequestWorkers et ThreadsPerChild nécessitent plus de 16 processus serveur (valeur par défaut).  
</td>

<td>
  20
</td>

<td>
    La directive StartServers définit le nombre de processus de serveur enfant créés au démarrage. Comme le nombre de processus est contrôlé dynamiquement en fonction de la charge, il y a généralement peu de raisons d'ajuster ce paramètre, sauf pour s'assurer que le serveur est prêt à gérer un grand nombre de connexions dès son démarrage.  
</td>

<td>
  25
</td>

<td>
    Cette directive définit le nombre de threads créés par chaque processus enfant, 25 par défaut. Il est recommandé de conserver la valeur par défaut car l'augmenter pourrait conduire à une dépendance excessive vis-à-vis d'un seul processus.  
</td>

Pour plus d'informations, veuillez consulter la documentation relative à la version d'Apache concernée :

• Apache 2.4 Directives communes de MPM

Exemple de configuration MPM du travailleur Apache 2.4 {#ApacheWebServer-ExampleApache2.4WorkerMPMConfiguration}

Cette section explique comment configurer Worker MPM pour un serveur Web RHEL7 Apache 2.4 nécessaire pour prendre en charge jusqu'à 500 utilisateurs simultanés de TrakCare.

1. Vérifiez d'abord le MPM en utilisant la commande suivante :
2. Modifiez le fichier de configuration /etc/httpd/conf.modules.d/00-mpm.conf selon les besoins, en ajoutant et en supprimant le caractère de commentaire # afin que seuls les modules Worker MPM soient chargés. Modifiez la section Worker MPM avec les valeurs suivantes dans le même ordre que ci-dessous :
3. Redémarrer Apache
4. Après avoir redémarré Apache avec succès, validez les processus worker en exécutant les commandes suivantes. Vous devriez voir quelque chose de similaire à ce qui suit confirmant le processus httpd.worker :

Renforcement d'Apache {#ApacheWebServer-ApacheHardening}

Modules requis pour Apache {#ApacheWebServer-ApacheRequiredModules}

L'installation du paquetage officiel d'Apache activera par défaut un ensemble spécifique de modules Apache. Cette configuration par défaut d'Apache chargera ces modules dans chaque processus httpd. Il est recommandé de désactiver tous les modules qui ne sont pas nécessaires à HealthShare pour les raisons suivantes :

• réduire l'empreinte du processus du démon httpd.
• réduire le risque d'un défaut de segmentation dû à un module malveillant.
• réduire les vulnérabilités en matière de sécurité.

Le tableau ci-dessous détaille les modules Apache recommandés pour HealthShare. Tout module qui ne figure pas dans la liste ci-dessous peut être désactivé :

Désactivation des modules

Les modules inutiles doivent être désactivés pour renforcer la configuration qui réduira les vulnérabilités de sécurité. Le client est responsable de la politique de sécurité du serveur web. Au minimum, les modules suivants doivent être désactivés.

Apache SSL/TLS {#ApacheWebServer-ApacheSSL/TLS}

Pour protéger les données en transit, assurer la confidentialité et l'authentification, InterSystems recommande que toutes les communications TCP/IP entre les serveurs et les clients de HealthShare soient cryptées avec SSL/TLS, et InterSystems recommande également d'utiliser HTTPS pour toutes les communications entre le navigateur client des utilisateurs et la couche serveur web de l'architecture proposée.   Veillez à consulter les politiques de sécurité de votre organisation pour vous assurer de la conformité à toute exigence de sécurité spécifique de votre organisation. 

Le client est responsable de la fourniture et de la gestion des certificats SSL/TLS. Si vous utilisez des certificats SSL, ajoutez le module ssl_ (mod_ssl.so).

Paramètres supplémentaires de durcissement d'Apache {#ApacheWebServer-AdditionalHardeningApacheParameters}

Pour renforcer la configuration d'Apache, apportez les modifications suivantes au fichier httpd.conf :

• TraceEnable doit être désactivé pour éviter les problèmes potentiels de traçage intersites.

• ServerSignature doit être désactivé afin que la version du serveur web ne soit pas affichée.

Paramètres de configuration supplémentaires d'Apache {#ApacheWebServer-SupplementalApacheConfigurationParameters}

Keep-Alive {#ApacheWebServer-Keep-Alive}

Le paramètre Apache Keep-Alive permet d'utiliser la même connexion TCP pour la communication HTTP au lieu d'ouvrir une nouvelle connexion pour chaque nouvelle demande, c'est-à-dire que Keep-Alive maintient une connexion persistante entre le client et le serveur. Lorsque l'option Keep-Alive est activée, l'amélioration des performances provient de la réduction de l'encombrement du réseau, de la réduction de la latence des requêtes ultérieures et de la diminution de l'utilisation du CPU causée par l'ouverture simultanée de connexions. L'option Keep-Alive est activée par défaut et la norme HTTP v1.1 stipule qu'elle doit être présumée activée.

Cependant, l'activation de la fonction Keep-Alive présente des inconvénients : Internet Explorer doit être IE10 ou supérieur pour éviter les problèmes de délai d'attente connus avec les anciennes versions d'IE. De même, les intermédiaires tels que les pare-feu, les équilibreurs de charge et les proxies peuvent interférer avec les "connexions TCP persistantes" et entraîner une fermeture inattendue des connexions.  

Lorsque vous activez la fonction "Keep-Alive", vous devez également définir le délai d'attente de cette fonction. Le délai d'attente par défaut pour Apache est trop faible et doit être augmenté pour la plupart des configurations, car des problèmes peuvent survenir en cas de rupture des requêtes AJAX (c'est-à-dire hyperevent). Ces problèmes peuvent être évités en s'assurant que le délai d'attente du serveur est supérieur à celui du client.  En d'autres termes, c'est le client, et non le serveur, qui devrait fermer la connexion.  Des problèmes surviennent - principalement dans IE mais dans une moindre mesure dans d'autres navigateurs - lorsque le navigateur tente d'utiliser une connexion (en particulier pour un POST) dont il s'attend à ce qu'elle soit ouverte. 

Voir ci-dessous les valeurs recommandées de KeepAlive et KeepAliveTimeout pour un serveur Web HealthShare.

Pour activer KeepAlive dans Apache, apportez les modifications suivantes au fichier httpd.conf :

Psserelle CSP {#ApacheWebServer-CSPGateway}

Pour le paramètre CSP Gateway KeepAlive, laissez la valeur par défaut No Action car le statut KeepAlive est déterminé par les titres de la réponse HTTP pour chaque requête.