Spécifier le matériel pour les taux de transfert minimums

Pour ce faire, vous devrez regrouper les serveurs web autour d'un serveur de base de données central. Par ailleurs, le plus gros (et le plus laid) du travail ici n'est pas de stocker ou de servir, mais d'acquérir des données à grande vitesse.

Vous êtes absolument doit d'effectuer une série de tests de performance avant de vous engager dans cette voie. Cela peut signifier qu'il faut obtenir des unités de démonstration auprès des vendeurs de matériel. Appelez l'un d'entre eux et discutez-en, les vendeurs sont habilités à organiser des démonstrations de matériel que vous pourrez utiliser pendant une semaine ou deux. IBM et HP sont tous deux très bien placés pour cela.

Je suis très préoccupé par le fait que la méthode de transfert de fichiers maladroite (BMP et FTP) soit combinée avec une attente de haute performance. Vous allez rencontrer des problèmes, notamment en ce qui concerne la rapidité avec laquelle FTP peut gérer les connexions. Pour l'argent supplémentaire que vous dépenserez pour les serveurs, vous pourrez peut-être acheter des unités de caméra plus flexibles. Comment ces caméras peuvent-elles accéder à un serveur FTP ? Ce sont des caméras IP ?

Architecture du stade : 2 serveurs de communication gérant l'acquisition des fichiers, l'entrée des données dans la base de données, puis le transfert vers le serveur web ou le stockage sur le réseau SAN. Chaque serveur est équipé d'une carte graphique à deux gigabits, d'un double quadruple cœur pour le traitement des images et d'un espace de stockage local minimal. 1 x serveur de base de données. Les spécifications de ce serveur doivent être moyennes, en fonction de l'endroit où vous allez effectuer votre traitement, de la quantité de métadonnées et de statistiques que vous souhaitez stocker, et du nombre de connexions d'utilisateurs simultanées que vous allez gérer. 1 ou 2 serveurs web. Là encore, les spécifications dépendent entièrement du nombre d'utilisateurs que vous devez prendre en charge, du fait qu'il s'agisse d'un site web public ou privé, et de l'endroit où vous choisissez de traiter vos images.

Ce que vous essayez de réaliser semble être un système de surveillance de la production au niveau de l'atelier. Si c'est le cas, c'est le genre de travail qui devrait être confié aux spécialistes de ce domaine (SCADA, etc.). Ces systèmes sont extrêmement coûteux, critiques en termes de sécurité et autres, et le fait d'avoir une équipe dédiée qui n'est que vaguement associée à l'informatique est une très bonne chose (tm).

En réponse à votre clarification concernant la quantité de données que vous capturez, ce type de volume représente un défi important. Vous indiquez qu'il s'agit d'une installation de fabrication, je suppose donc qu'il s'agit d'une exigence 24x365. Je ne vais parler ici que des volumes de stockage - d'autres ont fait des commentaires sur l'architecture de traitement, mais je pense qu'il est important que vous ayez une idée de l'échelle de la solution globale.

À 40MBytes/seconde, on parle d'un demi-pétaoctet par an s'il s'agit d'un processus continu et que l'on doit conserver tous les fichiers sur un support de stockage raisonnable. Si vous avez réellement besoin de faire cela, alors quelle que soit la solution de stockage que vous avez, elle vous fournira des performances d'E/S instantanées bien supérieures à ce dont vous avez besoin. Au minimum, si j'achetais un demi-pétaoctet de stockage à un fournisseur, je voudrais qu'il soit en mesure de fournir des options de stockage sur disque rapides et agréables en plus du volume. Quelle que soit la façon dont vous le construisez, un demi-pétaoctet de stockage sur disque sera coûteux et occupera une grande partie de l'espace du rack. Des matrices de disques 6x48 avec des disques SATA de 2 To occuperont la moitié d'un rack 42U et consommeront quelques kilowatts rien que pour tourner.

Il n'est cependant pas nécessaire de gaspiller autant d'espace disque - vous voulez abandonner le format BMP avant de les commit sur votre support. \long stockage à long terme. Si vous souhaitez conserver les données sans perte, le format PNG devrait vous permettre d'économiser entre 60 et 90 % par rapport au format BMP. Si la compression avec perte n'est pas si importante, le format JPEG vous permettra d'économiser entre 80 et 95 %, c'est pourquoi il est essentiel de mettre en place une pile de traitement qui convertit le format BMP avant de l'enregistrer sur un support permanent. Même dans ce cas, vous devrez disposer d'environ 50 To de stockage pour une année de données, ce qui n'est pas bon marché, mais vous pouvez trouver des solutions de stockage sur Internet. \build que pour le prix d'une voiture moyenne plutôt que pour les coûts de type Ferarri que vous coûterait quelque chose de l'ordre du pétaoctet. Si vous achetez autant d'espace, il devrait également être en mesure de vous fournir facilement la capacité de stockage IO élevée dont vous avez besoin pour le déchargement initial des caméras et pour votre base de données.

Votre base de données ne sera pas non plus insignifiante - si ces taux de capture sont maintenus (ce que je suppose s'il s'agit d'un processus de fabrication), vous aurez près de 2 millions d'enregistrements ajoutés par jour - 3/4 d'un milliard par an. Si chaque enregistrement ne représente qu'environ 1 000 caractères, votre base de données atteindra 600 Go. Il existe de nombreuses solutions capables de gérer cela, mais il ne s'agit pas d'une petite base de données, loin s'en faut.

Si mes hypothèses concernant l'exigence d'un processus 24x7 avec un débit de données constant sont erronées, tout cela est bien sûr excessif, mais même si ce processus ne fonctionne que 8x5 au lieu de 24x365, vous aurez besoin d'un SAN assez grand et robuste (coûteux) et il ne serait pas logique d'essayer ensuite d'entasser tous les services d'assistance (Web front end, etc.) dans un réseau de stockage. \DB\image traitement) dans une seule boîte.