Bonjour,
Ayant testé l'utilisation de mariadb sur le service Kubernetes managé, j'ai constaté que les bases de données situées dans un Block Storage n'était pas une solution appropriée pour un environnement de production:
Notre base de données (nécessitant 60 Go d'espace disque) requiert 20 000 IOPS pour fonctionner correctement alors que les disque SSD des Block Storage sont limités à 3 000 IOPS.
Les disques Gen2 ne sont non seulement pas disponible pour Kubernetes, mais également inapproprié étant données qu'ils offrent seulement 30 IOPS par Go de commandé, ce qui fait 1 800 IOPS pour une base de données de 60 Go, et est donc encore pire que la Gen1 en terme de performance.
L'utilisation de l'espace disque local des nodes est également inapproprié vu que l'espace local fait parties des éléments managé par OVH et donc susceptibles d'être effacé.
Est-ce qu'il existerait une solution pour héberger ma base de données sans risque de pertes de données et avec une performance 20 000 IOPS?
Performance en IOPS trop basses des Block Storage pour une base de données sur Cluster
Related questions
- Kubernetes loadbalancer IP source
7767
02.08.2019 06:18
- Pull image kubernetes
7462
08.11.2022 11:07
- Kubernetes dashboard
7003
02.12.2019 14:14
- Issues with Wordpress install guide
6849
13.12.2018 20:11
- Managed Kubernetes Platform is now live !
6329
27.02.2019 15:20
- All pods killed and to "Container Creating"
5947
13.02.2019 10:11
- Certificate order pending
5780
11.09.2023 19:32
- Erreur intempestive
5494
03.04.2019 17:18
- Guides pour la mise en place et l'utilisation des volumes
5448
10.04.2019 12:27
- Mémoire pod limitée java
4955
24.04.2019 22:19
monter un cluster mariadb sur 3 baremetals (mini).
Ou un baremetal seul, avec 1 seule bdd, mais pas de tolérance de panne dans ce cas.
Là je viens de tester sur un adv6 on est à 150k iops...
Même un VPS essential on dépasse les 10k iops.
Par contre pas compatible avec vrack.
Ils ne proposent tjrs pas le "managed baremetal" qu'on peut intégrer au cluster k8s ?
Pour le core infra ça serait l'idéal... Et ensuite les vms à l'heure qd il faut monter ponctuellement en puissance...
Hello @LDPROC
Je confirme que les disques high speed gen2 ne sont pas très adaptés à des usages cloud native.
Le plus simple pour de petites base de données est d'utiliser les offre de DBaaS offertes par OVHcloud. Un operateur kubernetes est même disponible pour en faciliter la gestion depuis Kubernetes.
L'autre solution est de déployer cette base hors K8s vous même, par exemple sur 2 instances.
Mes collègues du stockage travaillent sur une nouvelle classe très haute peformance, meme à petit volume, le printemps.
Merci pour votre réponse.
Je me demandais sinon si il était possible de commander seulement le Control Plane du service k8s managé et d'intégrer manuellement des instances au cluster, de sorte à garder la gestion de l'espace disque des instances?
des self-managed nodes ne sont pas disponibles pour le moment. Nous le proposerons probablement des control plane payant l'année prochaine pour cet usage, sur la base de notre future région 3AZ.
Dès ce printemps vous pourrez par contre déployer vos propres clusters self-managé avec RKE via Managed Rancher Service. L'alpha est accessible ici : https://labs.ovhcloud.com/en/managed-rancher-service/
@MaximeH1 Bonjour
Etant concerné par les mêmes interrogations, j'aimerais avoir une confirmation sur une mise en place possible.
D'après ce que je peux trouver dans la documentation https://help.ovhcloud.com/csm/en-ie-public-cloud-kubernetes-formating-nvme-disk-iops-nodes?id=kb_article_view&sysparm_article=KB0037312 il serait possible en exploitant un nodepool séparé d'exploiter des nodes « statiques » de la gamme IOPS / Storage optimized.
Dans cette configuration, le stockage est accessible sous la forme d'un volume local. De ce que je comprend de la documentation, le stockage NVME n'est pas effecté par les réinstallations du système (en cas de mise à jour du cluster par exemple) (là dessus, pas d'information très claire, que ce soit sur la page citée ou sur les documentation des instances IOPS / Storage optimized).
Cette solution permet-elle bien d'envisager d'exploiter des nodes via l'offre managé Kubernetes, sans perte de données (pour la partie sur les NVMe) lors des opérations de maintenance OVH, avec la contrepartie que les workloads doivent être assignées statiquement et que l'accès aux données est perdu si le host hébergeant l'instance IOPS rencontre un problème.