Depuis bien des années j’utilise des NAS Synology. D’une part pour stocker des fichiers liés à mon activité professionnelle, come stockage partagé de mon cluster de voyage (en plus d’utiliser le stockage cloud OneDrive et Dropbox synchronisés sur 4 appareils distincts !) mais aussi pour des besoins plus personnels comme le support des photos entre autres.
Pourquoi un NAS plutôt que des disques externes : tout simplement pour pouvoir bénéficier de la redondance RAID1 ou RAID5 offerte par ces boitiers. Oui, j’ai aussi des disques externes, en archive externalisée mais je n’ai qu’une trais faible confiance quant à la durabilité. 1 égale 0. Si vous perdez ce disque, vous avez tout perdu. 2 égale 1. Avec un RAID1, si un disque tombe en panne, vous avez la chance de récupérer vos précieuses données car elles sont également présentes sur le second disque.
Et pour être transparent, je n’ai pas 1 NAS, mais 3, avec des synchronisations entre ces différents appareils. Pour ceux qui ne me connaissent pas, oui, je travaille énormément sur les volets la partie HA et DR de SQL Server …
Revenons à nous moutons, ou à nos NAS. Pourquoi Synology ? Probablement parce qu’à mes yeux il s’agit du meilleur matériel, avec de surcroit une offre logicielle vraiment intéressante. Mais des constructeurs comme QNAP et autres ne sont pas loin, je ne veux pas déclencher une querelle de clochers.
Autre la gestion de mes fichiers, les NAS me servent de poste de pilotage pour la vidéo surveillance, mais également, certains modèles offrent la possibilité de prendre en charge vos sauvegardes, d’héberger des machines virtuelles ou de supporter l’exécution de conteneurs. L’article traitant des conteneurs, inutile de faire ici une liste exhaustive.
Car oui, j’ai des conteneurs qui tournent sur des VMs sur Hyper-V, mais également quelques conteneurs sur Raspberry Pi et encore d’autres sur le DSM Synology.
Sur ce Blog, plusieurs articles traitent de SQL Server dans un conteneur. Aucune raison donc de ne pas utiliser également le NAS, et cela fonctionne parfaitement.
Je vous laisse ajouter le module Docker à votre DSM.
Ensuite, si ce n’est déjà fait, c’est d’activer, au moins temporairement, l’accès SSH car il n’est pas possible d’ajouter la registry Microsoft à la configuration de Docker sur le NAS.
Tout comme on téléchargerait l’image sur un système Docker plus « traditionnel », on va se positionner en root et faire un Docker Pull.
sudo -i
docker pull mcr.microsoft.com/mssql/server:2019-latest
Petite vérification dans les images, mais en version graphique cette fois-ci :
Il ne reste plus qu’à créer le conteneur en cliquant sur bouton Launch et donner les paramètre d’environnement comme on le ferait en ligne de commande.
Et ensuite valider la création du conteneur. Le conteneur est créé et en cours d’exécution.
La connexion vers l’instance SQL est à présent possible
Happy SQL Server on Docker on Synology !
Christophe LAPORTE - Consultant 
bonjour Monsieur, merci pour ce tuto
Une question : est-il possible d’héberger SQL Server 2019 express edition (plus habitué de son utilisation que postgresql)
merci d’avance pour toute réponse
Bonjour
Le choix de la version et de l’édition est tout a fait possible lors de la création du conteneur. La variable d’environnement MSSQL_PID est faite pour cela. En l’occurrence la démonstration était faite avec l’édition Express.
merci beaucoup pour votre réponse rapide
cordialement
bonjour,
tout d abord merci pour l article.
Une petite question, avez vous une comparaison entre un serveur traditionnel et le docker sous synology ? je parle au niveau des performances processeurs ?
Car la vitesse des disques durs et le fait de les mettre en raid aussi, mais le niveau de perf du processeurs et de la ram est elle secondaire à votre avis?
Bonjour
Attention, il s’agissait bien sur d’un test. Et je ne partirai pas en production sur ce type d’environnement.
Mais pour répondre clairement à votre question : la performance d’un serveur SQL est directement lié à la fréquence du processeur et à la quantité de mémoire que l’on va attribuer à l’instance. Le nombre de cores ne fait qu’accroitre la charge possible. Mais la perf d’un requête n’est liée qu’à la fréquence du processeur. Donc exit les CPU à 2Ghz … Je ne serai que trop vous conseiller des processeurs > 3GHz.
Concernant les disques, oui c’est important, mais gardez à l’esprit que toutes les requêtes, hormis RESTORE DATABASE, s’exécutent … en mémoire.
S’il s’agit d’un SELECT, si les données sont en méméoire, on va donc aller à la vitesse de la RAM (nanoseconde en terme de latence et GigaHertz pour le processeur, pas de cycle d’attente, tout est synchronisé). Si les données ne sont pas dans le uffer pool, alors la requête va être palcée dans un état d’attente pour que des IO asynchrones puissent aller lire les données sur disque et le remonter en mémoire. Ensuite, le SPID va être reveillé et pourra poursuivre son exécution.
S’il s’agit d’une transaction, alors oui la vitesse du disque qui supporte le journal de transaction va directement impacter la performance car il s’agit ici d’un IO synchrone. D’où la préférence pour des disques à technologie flash qui ont uen latence à la micro seconde, contre des millisecondes pour des disques rotatifs.
Donc plus ondispose de RAM, mieux l’on se porte, car davantage de données peuvent être stockées dans le buffer pool. Une bonne base de travail : 6 à 8 GB de RAM par core. Plus, c’est encore mieux. Sinon, vous allez payer de la licence SQL pour attendre la remontée de données du disque vers la méméoire.
La parité (RAID 1, 5, 10, 50, 51) ne va pas vous apporter de gain de performance en écriture, … car il faut calculer la parité et effectuer plusieurs IO disque ! En lecture on peut avoir des gain, pour du RAID 1, 10 ou 51.
Ma préférence ira dont à un serveur traditionnel, avec ou sans virtualisation / containerisation, avec beaucoup de méméoire et des disques flash.
Mais pour le fun et faire des tests, cela fonctionne sur du Syno, et même un Raspberry Pi ( https://conseilit.wordpress.com/2021/01/06/sql-server-sur-raspberry-pi/ ).
Merci pour cette réponse détaillée.
Je vous avoue que je suis toujours en recherche de la bonne solution, étant en « conflit » avec un fournisseur de logiciel qui utilise une base SQL, et les temps de latence sur notre infra serait dûs à notre serveur sql, qu il soit virtualisé ou non (j ai essayé sous VMWare puis hyperV) que les disques ne soient pas assez rapides (j ai donc changé le disque pour en mettre un plus rapide en accès direct sur la machine virtuelle) la ram j ai mis 128go et 8 processeurs, mais les temps ne sont toujours pas là. Bref un chantier type électricienplombier.
Encore merci .
Je vous suggère de faire auditer votre infra (Matériel, virtualisation, OS, SQL, …) afin de ne pas laisser cette situation durer.
Merci. J avais déjà fait auditer l infra virtuelle, puis la base sql et son utilisation par le fournisseur de logiciels par une de vos collègues experte SQL, qui avait relevé la vitesse des hd (changés depuis) mais aussi les requetes de plus de 100 lignes du fournisseur.
Je vais toutefois tenter une machine physique dédiée à cette base sql .