Administration Guides

Selon les configurations, plusieurs vstore sont déployés :

un vstore dit 'technique' pour le stockage des objets du socle qui applique la politique ABAC du socle
un ou plusieurs vstore métier ayant des stockages backend spécifiques : à ce jour, postgresql ou tidb.

Configuration du vstore technique

Localisation

Le service est déployé dans kubernetes :

namespace : kosmos-datavirt
- pod : vstore-*

Configuration Initiale

Fichiers de configuration

Les éléments de configuration sont contenus dans le configmap du namespace :

> kubectl -n kosmos-datavirt get cm
NAME               DATA   AGE
kube-root-ca.crt   1      117d
vstore-config      3      117d

A l'installation d'une PF, la politique du socle choisie pour la PF est mise en place (voir procédure d'installation).

Cette politique est donc consultable dans la configMap vstore-config

Labels du socle : référentiel des labels

Les labels du socle et leurs valeurs sont gérés via le vstore et sont stockés dans la base sous-jacente au vstore technique (dans postgresql technique).

La base kosmos_back contient :

la table des labels, dont ceux du socle qui appartiennent au 'tenant_id' kosmos :

Consultable dans PGAdmin ou via PSQL dans un pod PG :

Exemple :

select id, i18n from label where tenant_id='kosmos';

 classification | {"fr-FR": {"plural": "Classifications", "values": [{"key": "NP", "value": "Non Protégé"}, {"key": "DR", "value": "Diffusion Restreinte"}], "singular": "Classification"}}
 organisation   | {"fr-FR": {"plural": "Zones", "values": [{"key": "p-hzjmn", "value": "DGA"}, {"key": "p-khfvx", "value": "IVVQ"}, {"key": "p-zwn9w", "value": "SSA"}, {"key": "p-v2mvq", "value": "CYBER"}, {"key": "p-mn7qv", "value": "formation"}, {"key": "p-6l87j", "value": "CND"}, {"key": "p-6rxvk", "value": "Projet-SCA"}], "singular": "Zone"}}
 environnements | {"fr-FR": {"plural": "Environnements", "values": [{"key": "BAS", "value": "Bac à Sable"}, {"key": "EID", "value": "Environnement d'intégration et de déploiement"}, {"key": "PROD", "value": "Production"}], "singular": "Environnement"}}
 environnement  | {"fr-FR": {"plural": "Environnements", "values": [{"key": "BAS", "value": "Bac à Sable"}, {"key": "EID", "value": "Environnement d'intégration et de déploiement"}, {"key": "PROD", "value": "Production"}], "singular": "Environnement"}}
 mention        | {"fr-FR": {"plural": "Mentions", "values": [{"key": "SF", "value": "Special France"}, {"key": "R", "value": "Restricted"}], "singular": "Mention"}}
 organisations  | {"fr-FR": {"plural": "Zones", "values": [{"key": "p-hzjmn", "value": "DGA"}, {"key": "p-khfvx", "value": "IVVQ"}, {"key": "p-zwn9w", "value": "SSA"}, {"key": "p-v2mvq", "value": "CYBER"}, {"key": "p-mn7qv", "value": "formation"}, {"key": "p-6l87j", "value": "CND"}, {"key": "p-6rxvk", "value": "Projet-SCA"}], "singular": "Zone"}}
(6 rows)

une table par ressource pouvant être protégée par la politique du socle (application, traitement (topology), ...) : ces tables sont mises à jour via les IHM qui permettent de gérer les ressources.

Modification du référentiel des labels

Le référentiel des labels (la table label) contient :

les labels des politiques BEC définies pour chaque zone : contenu administré par l'IHM GDA depuis le portail métier
les labels des utilisateurs (= attributs) définis pour chaque zone : ces attributs sont créés depuis l'IHM GDA coté métier mais ne peuvent pas être modifiés depuis l'IHM
les labels du socle qui s'appliquent aux objets du socle : ces labels ne peuvent pas être géré depuis l'IHM GDA.

Pour les labels ne pouvant pas être modifiés par l'IHM GDA, il est toujours possible de les modifier directement dans la base kosmos_back. Ce geste peut avoir des conséquencs importantes si un label ou une valeur est supprimé : accès impossible aux objets, erreur systèmatique de la politique du socle qui induit une indisponibilité des IHM métiers, voire du portail métier. Il faut donc être très vigilant concernant les modifications apportées.

Configuration des vstore métiers

Localisation

Le service est déployé dans kubernetes :

namespace : shared-htap
- pod : tidb-controller-manager-*
- pod : tidb-vstore-discovery-*
- pod : tidb-vstore-pd-*
- pod : tidb-vstore-tidb-*
- pod : tidb-vstore-tikv-*
namespace : shared-htap
- pod : vstore-bas-rw-*
- pod : vstore-eid-rw-*
- pod : vstore-prod-ro-*
- pod : vstore-prod-rw-*

Configuration Initiale

Dimensionnement

Le cluster est composé de 3 replicas minimum.

Chaque pod se voit attribuer les ressources suivantes :

tidb-controller-manager-* :

Requests:
- cpu: 80m
- memory: 50Mi

tidb-vstore-discovery-* :

Limits:
- cpu: 4
- memory: 8Gi
Requests:
- cpu: 4
- memory: 8Gi

tidb-vstore-pd-* :

Limits:
- cpu: 4
- memory: 8Gi
Requests:
- cpu: 4
- memory: 8Gi

tidb-vstore-tidb-* :

Limits:
- cpu: 4
- memory: 16Gi
Requests:
- cpu: 4
- memory: 16Gi

tidb-vstore-tikv-* :

Limits:
- cpu: 4
- memory: 32Gi
Requests:
- cpu: 4
- memory: 32Gi

vstore-* :

Requests:
- cpu: 2
- memory: 1Gi

Un volume est attaché à chacun des pods du cluster :

kubectl -n shared-htap get pvc
NAME                      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      VOLUMEATTRIBUTESCLASS   AGE
pd-tidb-vstore-pd-0       Bound    pvc-00ab0511-2f79-4cb4-9404-e75704a6adac   2Gi        RWO            lvm-provisioner   <unset>                 19d
pd-tidb-vstore-pd-1       Bound    pvc-5a276cc2-60c6-4f74-9ff3-9a8274d8b807   2Gi        RWO            lvm-provisioner   <unset>                 19d
pd-tidb-vstore-pd-2       Bound    pvc-8d53a484-3167-48bb-969f-3746aaa57ab5   2Gi        RWO            lvm-provisioner   <unset>                 19d
tikv-tidb-vstore-tikv-0   Bound    pvc-b6dc6c2f-b0a2-4952-9d4f-d059347d8935   20Gi       RWO            lvm-provisioner   <unset>                 19d
tikv-tidb-vstore-tikv-1   Bound    pvc-be444e0c-4ee3-411c-b70d-975b6c780236   20Gi       RWO            lvm-provisioner   <unset>                 19d
tikv-tidb-vstore-tikv-2   Bound    pvc-a13803e3-2055-4ce5-811b-2e99cbcbbcc3   20Gi       RWO            lvm-provisioner   <unset>                 19d

Paramétrage spécifique

Sans objet

Interfaces

Le service vstore utilisable par les applications est exposé sur le cluster Kubernetes :

kubectl -n shared-htap get svc
NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)               AGE
tidb-vstore-discovery   ClusterIP   10.234.184.199   <none>        10261/TCP,10262/TCP   29d
tidb-vstore-pd          ClusterIP   10.234.12.2      <none>        2379/TCP              29d
tidb-vstore-pd-peer     ClusterIP   None             <none>        2380/TCP,2379/TCP     29d
tidb-vstore-tidb        ClusterIP   10.234.189.67    <none>        4000/TCP,10080/TCP    29d
tidb-vstore-tidb-peer   ClusterIP   None             <none>        10080/TCP             29d
tidb-vstore-tikv-peer   ClusterIP   None             <none>        20160/TCP             29d
vstore-prod-ro          ClusterIP   10.43.42.6       <none>        9080/TCP              29d
vstore-prod-rw          ClusterIP   10.43.216.235    <none>        9080/TCP              29d
vstore-eid-rw           ClusterIP   10.43.196.86     <none>        9080/TCP              29d
vstore-bas-rw           ClusterIP   10.43.18.54      <none>        9080/TCP              29d

Fichiers clés

Fichiers de configuration

Les éléments de configuration sont contenus dans le configmap du namespace :

kubectl -n shared-htap get cm
NAME                           DATA   AGE
kube-root-ca.crt               1      29d
tidb-vstore-pd-3731616         2      29d
tidb-vstore-tidb-6662316       2      29d
tidb-vstore-tidb-initializer   3      29d
tidb-vstore-tikv-3831336       2      29d
vstore-config                  3      29d

Logs

Les logs sont consultables sur la sortie standard de kubernetes avec la commande logs.

Binaires

Combinaison de défaillance

Les données stockées dans le cluster peuvent être perdues dans certaines situations :

En cas de suppression/perte de tous les noeuds kubernetes constituant le cluster avec leurs disques attachés
En cas de nettoyage forcé (par exemple avec rm -rf ou destruction des pv) des volumes attachés aux pods

Backup technique

Prerequisites

When you want to back up with a s3 bucket, you need:

registry.technique.artemis/pingcap/br:v8.1.1 compatible avec LTS v8.1 et tidb v1.6.0
les secrets backup-tidb-secret et backup-tidb-s3-secret ne sont pas necessaire dans le cadre de backup orchestrés par EDS. EDS Backup gère ses propres secrets.
rbac.authorization:

kubectl apply -f- <<EOF
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tidb-backup-manager
  namespace: shared-htap
  labels:
    app.kubernetes.io/component: tidb-backup-manager
rules:
- apiGroups: [""]
  resources: ["events"]
  verbs: ["*"]
- apiGroups: ["pingcap.com"]
  resources: ["backups", "restores"]
  verbs: ["get", "watch", "list", "update"]
EOF

ServiceAccount:

kubectl apply -f- <<EOF
kind: ServiceAccount
apiVersion: v1
metadata:
  name: tidb-backup-manager
  namespace: shared-htap
EOF

RoleBinding:

kubectl apply -f- <<EOF
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tidb-backup-manager
  namespace: shared-htap
  labels:
    app.kubernetes.io/component: tidb-backup-manager
subjects:
- kind: ServiceAccount
  name: tidb-backup-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tidb-backup-manager
EOF

Witch backend TiDB

One shot

Documentation: https://github.com/pingcap/docs-tidb-operator/blob/master/en/backup-to-aws-s3-using-br.md

Backup resource to create from LTS v8.1 and tidb v1.6.0
BR/Dumpling DOCS: https://docs.pingcap.com/tidb/v8.1/br-snapshot-manual/#back-up-a-database

Example to backup the "test" database in an tidb-cluster into an s3 bucket "tidb-test-to-s3-shared/db-test-backup".

kubectl apply -f- <<EOF
apiVersion: pingcap.com/v1alpha1
kind: Backup
metadata:
  name: db-test-tidb-to-s3-shared
  namespace: shared-htap
spec:
  # tikv_version: v8.1.0
  toolImage: registry.technique.artemis/pingcap/br:v8.1.0
  serviceAccount: tidb-backup-manager
  backupType: "db" # full, db, table
  # backupMode: snapshot
  #tableFilter:
  #  - 'test*.*'
  storageSize: 10Gi
  # cleanPolicy: Retain
  from:
    host: tidb-vstore-tidb.shared-htap.svc.cluster.local.
    port: 4000
    user: root
    secretName: backup-tidb-secret
  podSecurityContext:
    #allowPrivilegeEscalation: true
    #capabilities:
    #  drop:
    #  - ALL
    runAsNonRoot: true
    runAsUser: 1000
  br:
    cluster: tidb-vstore
    clusterNamespace: shared-htap
    logLevel: info
    sendCredToTikv: true
    db: "test"
    # statusAddr: ${status_addr}
    # concurrency: 4
    # rateLimit: 0
    # timeAgo: ${time}
    # checksum: true
    # options:
    # - --lastbackupts=420134118382108673
  s3:
    provider: minio
    endpoint: http://s3.shared-s3.svc.cluster.local.:9000
    secretName: backup-tidb-s3-secret
    region: us-east-1
    bucket: tidb-test-to-s3-shared
    prefix: db-test-backup
EOF

Scheduled

Documentation: https://github.com/pingcap/docs-tidb-operator/blob/master/en/backup-restore-cr.md#backupschedule-cr-fields

Backup resource to create from LTS v8.1 and tidb v1.6.0
BR/Dumpling DOCS: https://docs.pingcap.com/tidb/v8.1/br-snapshot-manual/#back-up-a-database

Example to Schedule a backup for the "test" database in an tidb-cluster into an s3 bucket "tidb-test-to-s3-shared/db-test-backup".

kubectl apply -f- <<EOF
apiVersion: pingcap.com/v1alpha1
kind: BackupSchedule
metadata:
  name: db-test-tidb-to-s3-shared
  namespace: shared-htap
spec:

  maxBackups: 5
  #pause: true
  maxReservedTime: "3h"
  schedule: "*/30 * * * *"
  backupTemplate:
    # tikv_version: v8.1.0
    toolImage: registry.technique.artemis/pingcap/br:v8.1.0
    backupType: db  # full, db, table
    serviceAccount: tidb-backup-manager
    # backupMode: snapshot
    storageSize: 10Gi
  # cleanPolicy: Retain
    from:
      host: tidb-vstore-tidb.shared-htap.svc.cluster.local.
      port: 4000
      user: root
      secretName: backup-tidb-secret
    podSecurityContext:
    #allowPrivilegeEscalation: true
    #capabilities:
    #  drop:
    #  - ALL
      runAsNonRoot: true
      runAsUser: 1000
    br:
      cluster: tidb-vstore
      clusterNamespace: shared-htap
      logLevel: info
      sendCredToTikv: true
      db: "test"
      # statusAddr: ${status_addr}
      # concurrency: 4
      # rateLimit: 0
      # timeAgo: ${time}
      # checksum: true
      # options:
      # - --lastbackupts=420134118382108673
    s3:
      provider: minio
      endpoint: http://s3.shared-s3.svc.cluster.local.:9000
      secretName: backup-tidb-s3-secret
      region: us-east-1
      bucket: tidb-test-to-s3-shared
      prefix: db-test-backup
EOF

Restore

Documentation: https://github.com/pingcap/docs-tidb-operator/blob/master/en/restore-from-aws-s3-using-br.md

Example of restoring a backup of the "test" database in an tidb-cluster from an s3 bucket "tidb-test-to-s3-shared/db-test-backup".

kubectl apply -f- <<EOF
apiVersion: pingcap.com/v1alpha1
kind: Restore
metadata:
  name: db-test-tidb-to-s3-shared
  namespace: shared-htap
spec:
  toolImage: registry.technique.artemis/pingcap/br:v8.1.0
  serviceAccount: tidb-backup-manager
  backupType: "db" # full, db, table
  # backupMode: snapshot
  #tableFilter:
  #  - 'test*.*'
  storageSize: 10Gi
  # cleanPolicy: Retain
  to:
    host: tidb-vstore-tidb.shared-htap.svc.cluster.local.
    port: 4000
    user: root
    secretName: backup-tidb-secret
  podSecurityContext:
    #allowPrivilegeEscalation: true
    #capabilities:
    #  drop:
    #  - ALL
    runAsNonRoot: true
    runAsUser: 1000
  br:
    cluster: tidb-vstore
    clusterNamespace: shared-htap
    logLevel: info
    sendCredToTikv: true
    db: "test"
    # statusAddr: ${status_addr}
    # concurrency: 4
    # rateLimit: 0
    # timeAgo: ${time}
    # checksum: true
    # options:
    # - --lastbackupts=420134118382108673
  s3:
    provider: minio
    endpoint: http://s3.shared-s3.svc.cluster.local.:9000
    secretName: backup-tidb-s3-secret
    region: us-east-1
    bucket: tidb-test-to-s3-shared
    prefix: db-test-backup
EOF

Consulter un EDS vstore

Consulter les données

Les données stockées dans un EDS vstore sont consultables dans le moyen de stockage sous jacent (postgresql ou tidb), donc via les procédures dédiées à ces moyens de stockage.

Consulter les modèles et politiques

Le fichiers modeles et policies de chaque EDS vstore se trouvent dans des buckets du s3 métier : selon l'environnement de l'EDS, on retrouvera les fichiers dans différents buckets.

Il existe 3 buckets : 'policies', 'namespaces' et 'models' par environnement 'bas', 'eid', 'prod' et par mode d'accès 'rw' pour les environnements BAS et EID et 'ro' et 'rw' pour l'environnement de production :

Par exemple : pour un EDS vstore sur PG du bac a sable "ivvqvsbas", on retrouvera :

un fichier 'ivvqvsbas-policies.yaml dans le bucket vstore-bas-rw-policies
un fichier 'ivvqvsbas-models.yaml dans le bucket vstore-bas-rw-models
un fichier 'ivvqvsbas-namespaces.yaml dans le bucket vstore-bas-rw-namespaces

Troubleshooting

Déclaration erronée d'un EDS vstore

Si un EDS vstore est créé avec des fichiers non valides, le pod du vstore de l'environnement concerné peut se trouver en erreur.

Si tel est le cas, consulter les logs du pod en erreur qui indiquera l'EDS ou le fichier modele ou policy en cause.

Il faut alors supprimer l'EDS en cause, dans un premier temps via l'IHM EDS. Si ce n'est pas suffisant, accéder au bucket qui contient les fichiers pour supprimer le fichier en cause.

Configuration du vstore technique​

Localisation​

Configuration Initiale​

Fichiers de configuration​

Labels du socle : référentiel des labels​

Modification du référentiel des labels​

Configuration des vstore métiers​

Localisation​

Configuration Initiale​

Dimensionnement​

Paramétrage spécifique​

Interfaces​

Fichiers clés​

Fichiers de configuration​

Logs​

Binaires​

Combinaison de défaillance​

Backup technique​

Prerequisites​

Witch backend TiDB​

One shot​

Scheduled​

Restore​

Consulter un EDS vstore​

Consulter les données​

Consulter les modèles et politiques​

Troubleshooting​

Déclaration erronée d'un EDS vstore​

Configuration du vstore technique

Localisation

Configuration Initiale

Fichiers de configuration

Labels du socle : référentiel des labels

Modification du référentiel des labels

Configuration des vstore métiers

Localisation

Configuration Initiale

Dimensionnement

Paramétrage spécifique

Interfaces

Fichiers clés

Fichiers de configuration

Logs

Binaires

Combinaison de défaillance

Backup technique

Prerequisites

Witch backend TiDB

One shot

Scheduled

Restore

Consulter un EDS vstore

Consulter les données

Consulter les modèles et politiques

Troubleshooting

Déclaration erronée d'un EDS vstore