---
# System prepended metadata

title: Scalabilité Coltrane
tags: [' consolidaiton', coltrane, ' scalabitie']

---

---

tags : coltrane, consolidaiton, scalabitie
title : Scalabilité Coltrane
robots : noindex , nofollow
---

# Scalabilité Coltrane

[TOC]

## Séance du 29/09 : discussion autour du scénario matériel 

:::danger
TODO
>Ajout cinématique connexion à un questionnaire depuis le portail
>Ajout cinematique fonctionnement des batchs
:::

> Ce scénario avait été privillégié par Exist Solutions parmi les trois qui lui avaient été soumis ([voir => ](https://gitlab.insee.fr/sic/divers/suivi/-/wikis/Sc%C3%A9narios-%C3%A0-l'%C3%A9tude#sc%C3%A9nario-mat%C3%A9riel))
> participants : Benjamin, Céline, Guylène, Michael.

**Schéma**
![Schéma](https://gitlab.insee.fr/sic/divers/suivi/-/wikis/uploads/41ab5eedc9ae0c3489e81d97b4e6e3af/scenario-materiel.png) 

---
> 
> 
### Des variantes autour du rôle du reverse proxy

:::success
#### *Proposition de grille d'analyse pour les différentes variantes de scénarios*

**A étudier**
- fonctionnement du portail 
    - forme des URL (avantages/inconvenients pour l'utilisateur qui met l'URL orbeon en favori)
- fonctionnement du site miroir
- partie batch
        * chargement des forms
        * chargements des questionnaires personnalisés
        * extractions
        * courrier/mail : lien dans les courriers ?
- modele de données 
    - stockage éventuel de la correspondance entre l'orbeon et l'enquête...
        
**Coûts** 
- développement côté Coltrane
    - mise en place de la solution (mise en place de healtcheck par enquete ?)
    - organisation des travaux de dev sur les environnements de dev/qf/...
- côté CEI
    - impact à évaluer aussi en régime courant 
    - dépendance éventuelle vis à vis du CEI

**Plan de secours**
- Modalités de mise en oeuvre d'un plan de secours en cas de crash sur une base

:::

## Deux scénarii envisagés

### Une répartition portée entièrement par le reverse proxy
Cette répartition permettrait (à confirmer via un exemple) d'avoir de l'abstraction entre l'application (IHMs et batchs) et le stockage dans les bases Orbeon (pas nécessaire à l'application de connaître dans quel Orbeon sont stockées les données).
Les appels aux bases pourraient rester identiques, idem pour les Url d'accès à Orbeon !

:::danger
A évaluer selon la grille d'analyse + reproduire un exemple avec des URL
A creuser => quelle URL se retrouve dans la barre d'adresse des répondants une fois passé le reverse proxy
:::


### Une répartition portée à la fois par des URL signifiantes et le reverse proxy

Les URL "signifiantes" porteraient une information sur la répartition des données dans les bases orbeon.
Exemple à fournir : 

Sur la base de ces URL signifiantes une redirection pourra se faire au niveau du reverse proxy de façon fixe.

:::danger
A évaluer selon la grille d'analyse + reproduire un exemple avec des URL.
A creuser => quelle URL se retrouve dans la barre d'adresse des répondants une fois passé le reverse proxy.
:::

## Question de la répartition des enquêtes sur les différentes instances (T4 Orbeon + Bdd Exist)

### Niveau de granularité
Il ne semble pas utile d'aller en dessous du niveau Source pour gérer la répartition des enquêtes.

### Choix de répartition
Ce choix doit être porté par la maitrise d'ouvrage en fonction de différents paramètres : simultanéité des enquêtes, taille des échantillons, périodicité ?, importance stratégique de l'enquête....

## Niveau de service attendu de la solution
Le niveau de service proposé vise à être au moins aussi élevé que celui proposé actuellement, tout en minimisant les impacts éventuels d'un crash de la base Exist.

## Prochain point 
- D'ici 10/15j 

---

**Vu**
- [ ] Benjamin
- [ ] Céline
- [x] Guylène
- [x] Michael


