Parallelisation des jobs de calculs
Comment paralléliser complètement le calcul ?
Les étapes de calcul :
Elles sont au nombre de 4. Certaines prennent en paramètre le code insee de la commune sur laquelle elle travaillent, d'autres pas.
initGrid $codeInsee
initDatas
computeFactors $codeInsee
computeIndices
Principe de la parallélisation
Côté OpenShift
L'idée générale serait de déployer autant de jobs OpenShift que de communes, chaque jobs effectuant la totalité des 4 étapes sur une et une seule commune. Les périmètres de calculs sont alors distincts et on peut lancer plusieurs calculs en même temps.
Le nombre de jobs actifs en parallèle dépendrait directement des ressources que le cluster OpenShift est capable de nous allouer, sous réserve d'avoir réglé correctement
- les paramètres de
request
et delimits
des jobs - les quotas généraux du namespace
Ressources pour le job
resources:
requests:
cpu: 500mi
memory: 2000Mi
limits:
cpu: 500mi
memory: 2000Mi
Ressources pour le namespace
resources:
limits:
cpu: 2 ou 3
memory: 8000Mi à 10000mi
Côté Gitlab
Dans les références de Gitlab CI, il est possible de créer une matrice de déploiement qui lance automatiquement tous les déploiements en même temps. Les vocables parallel
et matrix
sont prévus à cet effet.
Ci-dessous la tâche "1.Init Grid" qui déploie autant de jobs que de communes.
1. Init Grid:
stage: Auto Deploy
variables:
NAMESPACE: "ns-$TRIGRAMME-$NAMESPACE_ENV"
parallel:
matrix:
- CALQUL_ACTION: init-grid
CODE_INSEE: [69003, 69029, 69033, 69034, 69040, 69044, 69046, 69271, 69063, 69273, 69068, 69069, 69071, 69072, 69275, 69081, 69276, 69085, 69087, 69088, 69089, 69278, 69091, 69096, 69100, 69279, 69142, 69250, 69116, 69117, 69381, 69382, 69383, 69384, 69385, 69386, 69387, 69388, 69389, 69127, 69282, 69283, 69284, 69143, 69149, 69152, 69153, 69163, 69286, 69168, 69191, 69194, 69202, 69199, 69204, 69205, 69207, 69290, 69233, 69292, 69293, 69296, 69244, 69256, 69259, 69260, 69266]
environment: dev $CALQUL_ACTION/$CODE_INSEE
before_script:
- *prepare_deployment
script:
- *apply_confs
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
tags:
- ns-arb-d01
Contrainte
Du fait qu'on ne maîtrise pas l'ordonnancement des jobs côté OpenShift (on ne sait pas dire à priori dans quel ordre ils vont être éligibles à l'exécution), il faut bien qu'on lance des job effectuant les 4 étapes de calcul sur une commune.
Questions
- Que se passe-t-il sur les zones limites des communes ?
Si deux jobs tournent en même temps sur deux communes ayant une limite commune, et qu'un job est à l'étape
computeFactors
alors que l'autre est àinitDatas
, est-il possible que certains facteurs soient calculé sur des zones finalement éliminées par dédoublonnage ?