Présentation

L’objectif de ce livre blanc est de vous aider à comprendre comment Self Help peut s’intégrer dans votre environnement technique.

Chaque infrastructure client étant unique par ses contraintes et choix technologiques, chaque projet fera l’objet d’une étude spécifique lors des phases d’avant-vente et/ou d’installation.

Glossaire des produits

Self Help repose sur trois fonctions principales :

• Une fonction de présentation des procédures et de l’agent virtuel.
• Une fonction d’édition des procédures et de l’agent virtuel.
• Un client lourd Self Help Studio installé sur les postes des rédacteurs des procédures.

En fonction de votre projet, les fonctions d'édition et de présentation peuvent être mutualisées sur une même machine ou réparties sur différentes machines. L’architecture cible et l’intégration dans votre infrastructure devra tenir compte de cette répartition.

Architecture globale

Composants des différents services

En fonction des architectures et de la charge, les serveurs d’édition et les serveurs de présentation peuvent être mutualisés sur une même machine.

Les serveurs sont installés à l’identique et peuvent supporter toutes les fonctions de Self Help.

Adaptabilité à vos contraintes

Une mise à l’échelle progressive

L’architecture de Self Help est évolutive ; elle peut être revue et modifiée en fonction de l’évolution de vos besoins. Vous pourrez ainsi démarrer votre projet sur un premier niveau d’architecture, puis revoir cette dernière si le nombre d’utilisateurs simultanés augmente, si vos règles de sécurité changent ou si vous ajoutez des fonctionnalités au périmètre initial de votre projet.

Chacune des couches peut être dimensionnée séparément avec plus ou moins de ressources en fonction des besoins identifiés. La montée en charge impacte principalement les serveurs de présentation Self Help.

Le schéma ci-dessous présente quelques exemples des architectures possibles des serveurs de présentation.

Nous ne préconisons pas de placer un serveur de présentation en DMZ mais d’utiliser un REVERSE PROXY afin de publier l’application.

Montée en charge

Nos services peuvent aller de plateformes simples avec deux serveurs, jusqu’à des configurations comprenant plusieurs dizaines de lignes, éventuellement réparties dans des zones de sécurité différentes.

Le premier critère de dimensionnement est lié à la montée en charge, l’objectif étant d’utiliser les deux dimensions qui sont à votre disposition.

• Scale IN : Ajout de ressources CPU ou MEMOIRE sur les machines existantes pour leur permettre de soutenir une plus grande charge. Si cette méthode est intéressante financièrement (moins de Vms à gérer, moins de licences, etc.), elle atteint rapidement ses limites car certaines ressources internes aux systèmes ne sont pas extensibles (thread, etc.).

• Scale OUT : Ajout de nouvelles machines qui assumeront une part de la charge. Cette solution est la plus souple mais elle impose de complexifier l’architecture en intégrant un load balancer pour répartir les utilisateurs sur les différents serveurs.

Quelle que soit l’architecture, et sans autre contrainte que celle de la montée en charge, il est toujours intéressant d’utiliser au maximum le SCALE IN avant d’ajouter de nouvelles machines.

Résilience

Quel est le taux de disponibilité souhaité de la plateforme ? Un taux important (24/7 par exemple) impliquera une architecture plus complexe, intégrant des lignes supplémentaires par rapport aux conditions souhaitées de montée en charge.

Ces plateformes supplémentaires absorberont la charge en cas de panne d’une des lignes de base définies comme nécessaires pour soutenir la charge visée.

La solution technique dépendra de la tolérance que vous souhaitez, et donc de la dégradation du service ou de sa perte temporaire totale. Voici quelques exemples :

• Perte temporaire d’une ligne Self Help : Ajouter une ligne supplémentaire.
• Perte temporaire d’un serveur de base de données : Le serveur de base de données doit être monté en cluster pour une plus grande disponibilité. Mais si une perte de quelques heures est tolérable, une remontée de VM et un restore de base de données peuvent être suffisants.
• Perte temporaire du load balancer : Mise en cluster du load balancer.

Nous vous conseillons d’intégrer ces ressources supplémentaires en permanence dans la chaîne de production plutôt que de les conserver éteintes et prêtes à être démarrées. Même si le coût d’une machine démarrée est supérieur à celui d’une machine éteinte, cela garantira totalement la bonne configuration / mise à jour de ces machines quand vous en aurez besoin.

Maintenabilité

Si votre politique sécurité vous impose une mise à jour régulière des systèmes d’exploitation, nous vous conseillons d’intégrer une ligne supplémentaire à ce qui a été déjà dimensionné pour la montée en charge.

Cette ligne supplémentaire, non intégrée dans le besoin en charge, va vous permettre de réaliser des mises à jour tournantes sur vos systèmes d’exploitation, sans pour autant impacter la production.

Voici un exemple avec trois lignes A, B et C (C ayant été ajoutée alors que seules A et B sont nécessaires pour la charge) :

• A et B en production, C est sortie de production + mise à jour + retour en production.
• A et C en production, B est sortie de production + mise à jour + retour en production.
• B et C en production, A est sortie de production + mise à jour + retour en production.

A chaque étape, deux lignes sont disponibles, ce qui ne pénalise pas vos utilisateurs.

Load balancer

Nos services peuvent être placés derrière un load balancer, notamment pour équilibrer la distribution des utilisateurs qui souhaitent se connecter sur les différentes lignes disponibles.

Votre load balancer doit permettre la "persistance des sessions", c’est-à-dire qu’un utilisateur déjà authentifié via une des lignes doit revenir sur cette ligne tant qu’il reste connecté. Dans le cas contraire, l’authentification précédente de l’utilisateur ne sera pas trouvée et le service lui demandera de se reloguer.

Reverse proxy

Nos services peuvent être placés derrière un reverse proxy. Le reverse proxy peut, entre autres, modifier le type de la requête (https en entrée vers http sur le frontal web), mais il ne doit pas :

• Modifier les paramètres passés.
• Modifier l’URL en elle-même (en ajoutant des répertoires, changeant le domaine, etc.).

Si le reverse proxy intègre des fonctionnalités de contrôle du contenu (WAF, antivirus, etc.), il ne doit pas modifier le contenu qui le traverse (paramètre, content, etc.) en dehors des paramètres HEADERS qui lui sont propres.

Sécurité de vos données en transit

Pour des raisons de confidentialité et d’intégrité des échanges, nous vous conseillons vivement de protéger les frontaux web Self Help par des certificats.

Nous vous préconisons de plus les points suivants :

• Utilisez les certificats fournis par un tiers reconnu. Les certificats privés fonctionnent mais généreront beaucoup d’erreurs lors des accès en mobilité hors de votre réseau (téléphones portables, etc.).
• Configurez votre couche SSL pour ne pas accepter les protocoles, ciphers, etc., connus comme faillibles : SSL v2, SSL v3, TLS v1.0, RC4, 3DES, etc.

Voici un exemple sur lequel vous baser pour la configuration de la couche SSL.

Besoin d’autres environnements

En plus de l’environnement de production, vous pouvez monter des environnements complémentaires pour répondre à vos contraintes d’organisation.

Nous vous recommandons de monter et de maintenir au moins un environnement supplémentaire qui vous permettra de tester des changements avant de les appliquer sur votre environnement de production. Notamment :

• Les fix ou les évolutions majeures de nos produits.
• Les changements de configuration des composants des serveurs (Apache, Tomcat, SSL, etc.).
• Les montées de version ou les fix des systèmes d’exploitation ou des composants des serveurs.

Navigateurs

Fournisseurs

Le marché des navigateurs étant en constante évolution, merci de vous référer à notre page wiki Navigateurs web pris en charge pour obtenir la liste à jour des navigateurs compatibles.

Configuration

Le cache local et les fichiers temporaires doivent avoir une limite suffisante (>10MB).

Si vous utilisez le protocole SSL, vérifiez que le cache de la page sécurisé est autorisé.

Autres

Nos services ne requièrent pas d’APPLET ou d’ActiveX sur le navigateur client.

Cookies

Nos services utilisent des cookies dans le but d’améliorer les fonctionnalités du site et l’expérience des utilisateurs. Les cookies ne contiennent aucune donnée personnelle ou critique.

Le navigateur doit autoriser nos services à créer des cookies.

Quelques exemples d’architecture

Architecture monoligne en LAN

Une seule ligne réduit les coûts d’hébergement, mais ne permet pas de garantir une disponibilité maximale.

Les serveurs de présentation et d’édition peuvent être regroupés sur une même machine, en dimensionnant en conséquence les ressources disponibles (CPU, RAM, Disque).
         

Architecture multiligne en LAN

L’architecture multiligne sur les serveurs de présentation permet de maîtriser la montée en charge (nombre de lignes de bases) et la haute disponibilité (une ligne en plus pour un service équivalent, même en perdant une des lignes).
         

Publication de l’application

La publication de Self Help sur l’internet est réalisée à l’aide d’un proxy.

Interopérabilité technique

Schéma de principe

Le schéma suivant présente les possibilités d’interopérabilité de Self Help.
         

REST

Fournisseur REST

Nous produisons des services accessibles en REST et SOAP 1.2.

Client REST et SOAP 1.2

Les services peuvent consommer des services REST ou SOAP 1.2 externes.

Messagerie

Self Help doit accéder à votre serveur de messagerie pour envoyer des e-mails à vos utilisateurs dans le cadre du traitement des incidents / changements.

Les protocoles suivants sont supportés : SMTP / SMTPS / SMTPS with TLS

Interopérabilité avec EasyVista Service Manager

Self Help communique avec Service Manager via des flux https/http pour les fonctionnalités suivantes :

• en fin de procédures Self Help, création de tickets via REST ou SOAP vers Service Manager ;
• Self Help Extractor : de Service Manager vers Self Help en https pour la consolidation des procédures dans la base de connaissance ;
• de Service Apps, pour la présentation des procédures Self Help en https.

Interopérabilité avec tout autre outil

Self Help communique avec votre outil via des flux https/http pour les fonctionnalités suivantes :

• En fin de procédures Self Help, création de tickets via REST ou SOAP vers votre outil.

Dimensionnement des serveurs

Attention : Ces chiffres sont donnés à titre indicatif car, en plus du nombre d’utilisateurs, les ressources nécessaires vont varier en fonction du nombre d’incidents/demandes créés quotidiennement, de l’activité web service et du type d’utilisation (Front Office, Back Office). Les abaques fournis ont été déterminés sur la base de notre expérience en SaaS.

Pour rappel, votre architecture cible sera constituée d’un ou plusieurs serveurs décrits ci-dessous.

Configuration des serveurs

Architecture mono-serveur

Cette architecture supporte l’ensemble des fonctionnalités de Self Help, soit :

• Les fonctions d’édition.
• Les fonctions de présentation des procédures.
• L’agent virtuel.
   

Présentation de la configuration :

Architecture multi-serveur de présentation

Cette architecture Self Help permet de :

• Dédier un serveur pour les fonctions d’édition.
• Dédier des serveurs pour des fonctions de présentation des procédures et l’agent virtuel.
   

Présentation de la configuration du serveur d’édition :

Présentation de la configuration du serveur de présentation :

Configuration du poste client pour le studio

Self Help Studio est une application Java/Eclipse RCP qui fonctionne en mode connecté ((port 80) ou https (port 443) sur TCP/IP) sur le serveur central d’édition. Elle nécessite comme unique infrastructure une machine virtuelle Java 1.8 fournie et installée avec le studio.

Configuration matérielle :

Le studio supporte de se connecter au serveur d’édition au travers d’un proxy d’entreprise.

Self Help

Prérequis techniques

Tous les serveurs d’une plateforme Self Help sont installés à l’identique, qu’ils aient le rôle de serveur de présentation ou d’édition.

Matrice de flux externe

Authentification des utilisateurs

Répartition des rôles

Pour Self Help, on distingue :

• L’authentification : Confirmation de l’identité de la personne qui cherche à se connecter.
• L’autorisation : Qu’est-ce que la personne qui a été identifiée a le droit de faire sur Self Help.

Authentification des utilisateurs dans Self Help

Self Help couplé avec Service Manager

Self Help dispose des moyens d’authentification suivants :

• Authentification par la base des employés internes de l’application.
• Authentification à travers de Service Manager.

Les authentifications supportées par Service Manager sont :

• Authentification par la base des employés internes de l’application.
• Authentification reposant sur votre (ou vos) annuaire(s) LDAP/AD.
• Authentification reposant sur un SSO compatible avec nos services.

Self Help en standalone

Self Help peut être connecté à tout autre outil sans l’application Service Manager.

Self Help dispose des moyens d’authentification suivants en natif :

• SSO SAML en tant que client de votre système de SSO.
• Authentification sur vos servers LDAP par bing.
• Authentification par la base des employés internes de l’application.

Annexes

Network

IPV6 n’est pas utilisé. Vous pouvez désactiver cette couche si besoin sur vos serveurs.

Antivirus

L’antivirus local doit être configuré pour ne pas scanner les répertoires suivants :

• Répertoire de stockage des logs applicatifs (fichiers au format XML).
• Répertoire de stockage des bases, des logs.

Configuration Apache

Liste des modules à intégrer :

• rewrite
• headers
• proxy
• proxy_http
• expires
• socache_shmcb_module
• deflate
• setenvif
• ssl