A propos de la structure du serveur Harmony

L'objectif principal du serveur de base de données est d'héberger et de gérer les informations sur les scènes Harmony. En option, il peut également héberger les données de scènes proprement dites, mais d'autres machines de votre réseau peuvent également être utilisées pour le stockage des données de scènes, car il s'agit de deux composants différents d'une base de données Harmony.

Une base de données Harmony est structurée à l'aide de différents partages réseau :

Le partage /USA_DB, qui contient les informations sur toutes les scènes, tous les environnements, tous les travaux ainsi que les ressources partagées telles que les palettes et les modèles stockés dans les environnements ou les travaux. Cette partie de la base de données doit être hébergée sur la machine qui exécute le service/daemon du serveur de base de données, auquel les postes de travail clients se connecteront directement.

Les partages /usadata, qui contiennent les données réelles de la scène : les dessins, l'animation, les modèles 3D, les palettes de scène, etc. Ils peuvent être hébergés sur le serveur de base de données ou sur n'importe quelle machine du réseau local à laquelle les postes de travail clients peuvent accéder. Il peut y en avoir autant que le studio en a besoin, ce qui vous permet d'étendre la capacité de stockage de votre serveur de base de données en créant un nouveau partage /usadata sur un nouveau serveur de fichiers.

Sur les machines clientes, chaque partage réseau est monté au même endroit que l'emplacement du partage réel sur leur serveur respectif. De même, si d'autres serveurs sont utilisés pour stocker les données de scène, les partages de ces serveurs sont montés sur le serveur de base de données. Il en résulte que la structure des fichiers de la base de données est entièrement accessible sur toutes les machines du réseau.

Si vous avez l'intention d'utiliser plusieurs partages /usadata, ils doivent être numérotés. La meilleure pratique consiste à nommer le premier partage /usadata /usadata000, et il est courant, bien que non obligatoire, de stocker ce partage sur la même machine que le serveur de base de données. Ensuite, lorsque vous avez besoin d'augmenter l'espace de stockage de votre base de données Harmony, vous pouvez créer un partage nommé /usadata001 sur une autre machine, et un autre nommé /usadata002 sur une autre machine, etc.

Au final, les machines clientes localiseront les différents partages qui composent votre base de données en montant ces points de partage sur la racine du système de fichiers de la machine cliente.

Sur les machines Windows, cela se fait en ajoutant des fichiers de raccourci (.lnk) à la racine d'un lecteur (typiquement C :) qui pointent vers le chemin réseau du partage, par exemple :

Un fichier de raccourci USA_DB.lnk pointant sur \dbserver\USA_DB.
Un fichier de raccourci usadata000.lnk pointant sur \dbserver\usadata000.
Un fichier de raccourci usadata001.lnk pointant vers \Nnewfileserver\Nusadata001.

Ce processus est effectué automatiquement par Configuration Wizard, un outil de configuration exclusif à Windows pour Harmony.

Sur les machines macOS et GNU/Linux, cela se fait en montant les partages sur des dossiers situés à la racine du système de fichiers. En donnant à ces dossiers le nom de leurs partages respectifs, cela simule la présence des fichiers du serveur sur le système de fichiers de la machine. Par exemple, un répertoire nommé /USA_DB :

Un répertoire nommé /USA_DB est monté avec le partage NFS à l'adresse dbserver:/USA_DB.
Un répertoire nommé /usadata000 est monté avec le partage NFS à l'adresse dbserver:/usadata000.
Un répertoire nommé /usadata001 est monté avec le partage NFS à l'adresse newfileserver:/usadata001.

En règle générale, les clients et les serveurs peuvent communiquer sans problème s'ils utilisent le même type de système d'exploitation. Il est possible de mettre en place une base de données Harmony qui mélange différentes plates-formes entre le serveur de base de données, les serveurs de fichiers et les postes de travail clients, mais avec certaines limitations importantes qui doivent être prises en compte :

Par défaut, l'utilisation de caractères Unicode non alphanumériques, à l'exception du tiret et du trait de soulignement, dans Harmony pour nommer les scènes, les calques et les dessins n'est pas activée, mais peut l'être en option. Cependant, vous devez absolument garder à l'esprit que macOS et GNU/Linux ne parviennent généralement pas à communiquer les noms de fichiers contenant des caractères Unicode via le protocole NFS.

Cela signifie que si Unicode est activé dans votre base de données, et qu'un client basé sur macOS essaie d'ouvrir ou de sauvegarder une scène contenant des caractères Unicode qui est hébergée sur un serveur de fichiers basé sur GNU/Linux, Harmony échouera à ouvrir et à sauvegarder des fichiers avec des caractères Unicode dans leur nom, et il pourrait y avoir une perte de données ! Il est donc important de ne jamais activer Unicode si votre réseau comprend des clients basés sur MacOS et des serveurs de base de données ou des serveurs de fichiers basés sur GNU/Linux, y compris des serveurs NAS basés sur GNU/Linux.
Si vous configurez votre serveur de base de données sur une machine Windows, seuls les clients Windows sont pris en charge. Il peut être possible de connecter un poste de travail client basé sur macOS ou GNU/Linux à un serveur de base de données basé sur Windows, mais cela peut entraîner des problèmes inattendus et ce n'est pas un scénario d'utilisation pris en charge.
Si vous avez l'intention de configurer votre serveur de base de données sur une machine macOS et que vous souhaitez que les postes de travail Windows puissent s'y connecter, vous devrez installer un logiciel tiers, SMBup, et le configurer pour partager les fichiers de votre base de données via le protocole Samba. En effet, macOS supporte nativement le protocole de partage NFS, mais pas SMB, et Windows supporte nativement le protocole de partage de fichiers SMB, mais pas NFS.

Pour résumer, voici un tableau décrivant les implications du mélange de plateformes entre serveurs et clients :