Quel serveur SQL choisir pour 1c 8.3. Choisir un sous-système de disque

Protection. La sauvegarde consomme également des ressources, pour ne pas perturber le travail, des ressources supplémentaires doivent lui être allouées. Les pare-feu, antivirus et autres outils de sécurité nécessitent également une certaine puissance.

Tolérance aux pannes. Disques ou alimentations remplaçables à chaud, redondance du système. Possibilité de remplacement rapide des composants. Plus la tolérance aux pannes est élevée, moins il y a de chance qu'il soit simple à utiliser. La plus grande tolérance aux pannes est obtenue dans le cluster.Serveur pour 1C par le nombre d'utilisateurs

C'est un paramètre clé dans le choix de l'équipement. Il est recommandé de vous familiariser afin d'avoir au moins une idée approximative de ce dont vous pourriez avoir besoin dans le processus de formation d'une configuration.

Serveur 1C pour 5 utilisateurs

Non requis pour 5 personnes hautes capacités, les configurations de petites entreprises sont très bien. Si le bureau est petit et que vous avez besoin d'un emplacement compact, vous pouvez utiliser un mini-serveur . Cette option vous permettra de placer l'équipement de manière compacte et sera pratique pour le transport.

Le coût d'un tel appareil est de 30 000 roubles. La configuration, en règle générale, ne diffère pas dans les délices. Un processeur d'entrée de gamme de la série Intel Xeon E3 ou AMD Opteron est utilisé. Il existe de nombreux assemblages prêts à l'emploi pour cette tâche. Mais dans le cas des appareils bon marché, il n'y a pas de disques SSD et de marge pour les charges de pointe.

Serveur 1C pour 10 utilisateurs

La configuration pour 10 employés est similaire à la solution précédente, aucune alimentation particulière n'est requise, il suffit d'utiliser un mini-serveur. Mais la charge de pointe doit être prise en compte, s'il y a des actions automatisées, telles que la génération automatique de rapports à partir de la boutique en ligne, alors la charge peut être beaucoup plus grave.

Ici, vous pouvez également vous débrouiller avec un processeur de la gamme Intel Xeon E3, par exemple le modèle 1240. La RAM suffit pour 8 Go, mais 16 c'est mieux, et il vaut également la peine d'utiliser un SSD pour héberger l'application et la base de données.

Serveur 1C pour 20 utilisateurs

Ici, vous avez besoin d'un équipement plus puissant que dans la version précédente. L'option pour une entreprise de taille moyenne est optimale. Le SSD dans un tel système doit être présent par défaut, et il est recommandé d'utiliser au moins le processeur Intel Xeon E3-1280 v6. Sinon, il n'y aura pas de marge pour la puissance de crête.

Serveur 1C pour 50 utilisateurs

Dans cette configuration, il est recommandé de prendre en compte la complexité des tâches. S'ils ne créent pas une charge importante, des capacités élevées ne sont pas nécessaires. S'il existe un volume de base de données important ou important, un équipement avec une intensité de ressources élevée sera nécessaire, dans certains cas, un cluster de périphériques est requis.

Habituellement, pour cette tâche, un système à deux processeurs basé sur Processeurs Intel Xeon E5-2643 v4. 2 de ces CPU sont capables de couvrir les besoins d'une application et même d'une base de données. Mais, idéalement, la création du serveur SQL est distincte.

Bien sûr, dans ce cas, les disques SSD ne sont plus seulement recommandés, mais vitaux, sinon le sous-système de disque deviendra un goulot d'étranglement.

Serveur 1C pour 100 utilisateurs

Dans ce cas, un seul appareil ne suffit pas. Souvent, un cluster de serveurs 1C est nécessaire, capable d'effectuer des opérations en parallèle et conjointement. Le développement individuel est requis.

Mais la configuration approximative serait comme ceci :

1. Serveur d'applications terminal. 2 processeurs Intel Xeon Silver 4215 pour accueillir une application SSD à TDW élevé, deux alimentations, un sous-système de disque pour les sauvegardes de l'état du système.

   Serveur SQL. Processeurs similaires, SSD avec DWPD élevé, également deux alimentations et un sous-système de disque avec RAID 1 pour le stockage des sauvegardes.

Ceci est conditionnel, les détails dépendront de l'infrastructure technique finale.

Serveur pour 1C pour 200 utilisateurs ou plus

Avec un tel nombre d'utilisateurs, un équipement de pointe est nécessaire pour faire face à des tâches de toute complexité. Comme dans la version précédente, un seul appareil ne suffira pas, il vous faudra un cluster. Plus le nombre total d'appels à la base de données et le nombre d'employés sont élevés, plus des équipements puissants seront nécessaires et, par conséquent, plus d'appareils dans le cluster. Il n'y a pas de solutions universelles, chacune est élaborée individuellement.

1C : Enterprise 8 peut être une application gourmande en ressources, même avec un petit nombre d'utilisateurs. En choisissant un serveur pour 1C, tout propriétaire souhaite éviter le "traumatisme de la naissance" - les goulots d'étranglement potentiels qui lui sont inhérents. D'autre part, aujourd'hui, peu de gens achètent des serveurs avec une capacité excédentaire, "pour la croissance". C'est bien si le profil de charge peut être supprimé à l'avance - il est alors plus facile de concevoir un serveur pour une configuration spécifique des applications d'une entreprise.

Pour être précis, considérons la plate-forme "1C: Enterprise 8.2" dans ses configurations de base populaires "Comptabilité", "Commerce et entrepôt", "Gestion des salaires et du personnel", "Gestion Entreprise commerciale"Et, en partie," Manufacturing Enterprise Management ". Nous partons du fait que pour les entreprises de 10 salariés ou plus travaillant en 1C, 1C : Entreprise 8.2. Serveur d'applications". Prenons en compte la possibilité de travailler en mode Bureau à distance, avec un nombre d'utilisateurs simultanés de la base de données allant jusqu'à 100-150. Les recommandations seront applicables pour des bases de données 1C plus « lourdes », mais les « cas graves » nécessitent toujours une approche individuelle.

Processeurs et RAM

Si l'entreprise est très petite (2-7 utilisateurs dans le système), la base est petite (jusqu'à 1 Go) et "1C: Enterprise 8.2" fonctionne en mode fichier sur l'ordinateur de l'utilisateur, alors on obtient l'implémentation classique du serveur de fichiers. Même Intel Core i3, en particulier Intel Xeon E3-12xx, peut faire face à une telle tâche en termes de charge CPU. La quantité de RAM requise (RAM) est considérée tout simplement : 2 Go pour le système d'exploitation et 2 Go pour le cache de fichiers système.

Si l'entreprise compte 5 à 25 utilisateurs 1C, la taille de la base de données peut aller jusqu'à 4 Go, alors l'application « 1C : Enterprise 8.2 » devrait avoir suffisamment d'Intel Xeon E3-12xx à 4 cœurs ou d'AMD Opteron 4xxx. En plus des 2 Go de RAM pour l'OS, il faut allouer 1 à 4 Go pour 1C : Enterprise 8.2. Serveur d'applications "et la même quantité pour MS SQL Server qu'un cache - un total de 8 à 12 Go de RAM. Pour les petites bases de données, il est souhaitable de mettre en cache au moins 30% de la base de données en RAM, et 100% c'est mieux.

Fait connu (bien que pas particulièrement annoncé) : « 1C : Enterprise 8.2. Application Server "n'aime vraiment pas quand le système d'exploitation le décharge dans un fichier d'échange sur Disque dur, et est enclin à parfois perdre la réponse. Par conséquent, le serveur exécutant le « Serveur d'applications » doit toujours disposer d'une réserve d'espace libre en RAM - d'autant plus qu'il est aujourd'hui peu coûteux.

Dans les grandes entreprises, les utilisateurs 1C travaillent généralement via un accès à distance à l'application (Remote Desktop) - c'est-à-dire en mode terminal. En règle générale, avec 10 à 100 utilisateurs 1C avec une base de données de 1 Go ou plus, « 1C : Enterprise 8.2. Le serveur d'applications " et l'application utilisateur " 1C : Enterprise 8.2 " sont lancés sur le même serveur.

Pour déterminer les ressources processeur requises, il est supposé qu'un cœur physique ne peut traiter efficacement pas plus de 8 threads utilisateur - cela est dû à l'architecture interne des processeurs. Comme le montre la pratique, pour les tâches 1C + Bureau à distance, vous ne devez pas utiliser de processeurs de serveur bas de gamme avec de faibles fréquences de cœurs de calcul et une architecture simplifiée. S'il y a peu d'utilisateurs (jusqu'à 15-20), un processeur de l'Intel Xeon E3-12xx haute fréquence suffira. Dans le même temps, au moins un de ses cœurs physiques (2 threads) ira aux besoins de SQL Server, un autre (2 threads) - sous « 1C : Enterprise 8.2. Serveur d'applications ", et les 2 cœurs physiques restants (4 threads) sont destinés aux utilisateurs du système d'exploitation et des terminaux. Si le nombre d'utilisateurs 1C est supérieur à 20 ou si la taille de la base de données est supérieure à 4 Go, il est temps de passer aux systèmes à 2 processeurs basés sur Intel Xeon E5-26xx ou AMD Opteron 62xx.

Le calcul de la quantité de RAM requise est relativement simple : 2 Go doivent être attribués au système d'exploitation, 2 Go ou plus - à MS SQL Server en tant que cache (au moins 30 % de la base de données), 1 à 4 Go - sous « 1C : Entreprise 8.2. Application Server », le reste de la mémoire du serveur devrait être suffisant pour les sessions de terminal. Un utilisateur du terminal, selon la configuration, consomme dans les applications "Comptabilité", "Commerce et entrepôt" - 100-120 Mo, "Gestion des salaires et du personnel", "Gestion d'entreprise commerciale" - 120-160 Mo, "Manufacturing Enterprise Management" - 180-240 Mo. Si l'utilisateur lance également MS Word, MS Excel, MS Outlook sur le serveur, alors pour chaque application, il est nécessaire d'allouer environ 100 Mo de plus. En règle générale, le minimum pour un serveur Terminal Server est de 12 Go de RAM.

Par exemple, pour un serveur 1C avec l'ensemble du progiciel, 50 utilisateurs de terminaux en configuration « Trade Enterprise Management », et une base de données de 8 Go, la puissance de calcul de deux processeurs Intel Xeon E5-2650 (8 cœurs, 16 threads, 2,0 GHz ) sera optimale. La RAM aura besoin d'au moins 2 (OS) + 4 (SQL) + 4 (serveur 1C) + 8 (160 "USP" * 50 utilisateurs) = 18 Go, ou mieux 24-32 Go (6-8 canaux DIMM de 4 Go).

Sous-système de disque

La plupart des plaintes concernant la lenteur de fonctionnement des serveurs 1C : Enterprise 8 sont liées à un manque de compréhension des types d'opérations d'E/S qui y sont effectuées, sur quelles données et avec quelle intensité. Souvent, c'est le sous-système de disque qui est la clé pour assurer des performances suffisantes du serveur dans son ensemble - après tout, pour les bases de données chargées, le plus gros problème est le verrouillage des tables lorsque de nombreux utilisateurs travaillent avec elles en même temps ou pendant des charges massives / déchargements / affichages. Surveillance et optimisation du sous-système disque du serveur.

1C dispose de 5 flux de données pour le sous-système de disque, avec lesquels il fonctionne :

• tables de base de données;
• fichiers d'indexation ;
• fichiers temporaires tempDB ;
• fichier journal SQL ;
• fichier journal des applications utilisateur 1C.

La structure de données dans 1C est orientée objet, avec de nombreux objets et connexions entre eux. Pour travailler avec des tables de données, le nombre d'opérations de lecture et d'écriture que le sous-système de disque peut effectuer sur une période de temps (opération d'entrée/sortie par seconde, IOPS) est extrêmement important. Dans le même temps, sa capacité à délivrer un débit de transfert de données en streaming élevé (en MBp/s) est beaucoup moins importante. Une base très modeste de 200 à 300 Mo avec 3 à 5 utilisateurs peut générer des pics allant jusqu'à 400 à 600 IOPS. Une base pour 10 à 15 utilisateurs et un volume de 400 à 800 Mo est capable de fournir 1 500 à 2 500 IOPS, 40 à 50 utilisateurs d'une base de données de 2 à 4 Go génèrent 5 000 à 7 500 IOPS, et les bases pour 80 à 100 utilisateurs atteignent facilement 12 000. 18000 IOPS.

Bien entendu, la charge moyenne sur le sous-système de disque peut être de 10 à 15 % du pic. Seulement en réalité, ce sont les performances lors des pics de charge qui sont importantes : téléchargements automatiques données d'autres systèmes, échange de données de système distribué ou repositionnement de période.

Les disques modernes dans les opérations de lecture et d'écriture avec accès aléatoire (Random Read / Write) font face à de telles charges :

On voit bien que :

• le goulot d'étranglement pour le disque dur et le SSD est l'enregistrement ;
• les disques durs traditionnels ne sont pas concurrents des SSD en termes de vitesse de lecture en IOPS, même théoriquement, la différence dépasse deux ordres de grandeur ;
• pas même le SSD de bureau le plus moderne 3 à 40 fois (selon la configuration) ne surpasse n'importe quel disque dur en vitesse d'écriture IOPS, le SSD du serveur est 12 à 40 fois plus rapide que le disque dur ;
• La classe SSD PCIe Intel 910 ou LSI WarpDrive offre des performances IOPS maximales.

Les disques uniques ne sont pas utilisés dans les serveurs de base de données, mais uniquement les matrices RAID. Pour calculer davantage les performances réelles du sous-système de disque, vous devez prendre en compte les coûts ("pénalités") d'écriture sur IOPS, qui sont supportés par le groupe de disques dans le RAID :

Si vous collectez 6 disques en RAID 10, alors pour chaque enregistrement de 1 IOPS de données, 2 IOPS de disques physiques seront dépensés, et si en RAID 6, alors 6 IOPS de disques. Ainsi, lors du calcul de la capacité de charge en écriture d'un groupe de disques, vous devez d'abord additionner les IOPS de tous les disques d'un groupe RAID, puis les diviser par une « pénalité ».

Exemple 1 : 2 HDD SATA 7200 en RAID 1 permettront d'écrire : (100 IOPS * 2) / 2 = 100 IOPS.

Exemple 2 : 4 SATA 7200 en RAID 5 fourniront l'écriture : (100 IOPS * 4) / 4 = 100 IOPS.

Exemple 3 : 4 SATA 7200 en RAID 10 permettront d'écrire : (100 IOPS * 4) / 2 = 200 IOPS.

Les exemples 2 et 3 illustrent pourquoi RAID 10 est préférable pour stocker des bases de données avec une allocation typique de lecture/écriture de 68/32.

A partir de ces trois tableaux, il est clair pourquoi les performances d'un "gentleman's set" typique 2 HDD SATA 7200 en RAID 1 ne sont pas suffisantes pour un serveur : aux pics de charge, la file d'attente des demandes de disque s'allonge, les utilisateurs attendent une réponse du système , parfois pendant plusieurs heures.

Comment puis-je augmenter les performances d'écriture du sous-système de disque ? Augmentez le nombre de disques dans un groupe RAID, déplacez-vous vers des disques avec une vitesse de rotation plus élevée, sélectionnez un niveau RAID avec une pénalité d'écriture inférieure. La mise en cache par un contrôleur RAID avec écriture différée activée aide beaucoup. Les données ne sont pas écrites directement sur les disques (comme dans le mode Write Through), mais dans le cache du contrôleur, et seulement ensuite, en mode batch et sous forme ordonnée, sur les disques. Selon les spécificités de la tâche, les performances d'enregistrement peuvent être augmentées de 30 à 100 %.

Pour les bases de données peu chargées ou relativement petites (jusqu'à 20 Go), une méthode peu coûteuse d'"extraction d'IOPS" convient - un RAID hybride à partir d'un SSD / HDD. Il n'est pas nécessaire d'avoir une base de données de succursales pour 3 à 15 utilisateurs dans une structure distribuée comme un réseau de cafés ou de stations-service.

Pour les bases de données volumineuses (200 Go ou plus) avec une longue boucle de données historiques, ou pour la maintenance de plusieurs bases de données volumineuses, la mise en cache SSD (technologies LSI CacheCade 2.0 ou Adaptec MaxCache 3.0) peut être efficace. Selon l'expérience de l'exploitation de tels systèmes, c'est dans les tâches 1C qu'ils peuvent être utilisés de manière relativement peu coûteuse et sans modifications significatives de l'infrastructure de stockage pour accélérer les opérations de disque de 20 à 50 %.

Le champion des performances en IOPS est, comme on pouvait s'y attendre, les baies RAID sur les SSD de serveur - à la fois traditionnelles, utilisant un contrôleur SAS RAID, et les SSD PCIe. Leur popularité est freinée par deux contraintes : technologiques (les performances des contrôleurs RAID ou la nécessité de casser radicalement la structure de stockage) et le coût de mise en œuvre.

Séparément, il faut dire à propos du stockage des fichiers d'index et de TempDB. Les fichiers d'index sont mis à jour très rarement (généralement une fois par jour), mais ils sont lus très, très souvent (IOPS). De telles données doivent simplement être stockées sur un SSD, avec leurs lectures ! TempDB utilisé pour stocker des données temporaires, en règle générale, est de petite taille (1-4-12 Go), mais ils sont très exigeants en vitesse d'écriture. La chose commune à propos des fichiers d'index et temporaires est que leur perte n'entraîne pas la perte de données réelles. Cela signifie qu'ils peuvent être situés sur un SSD séparé (encore mieux - sur deux volumes séparés). Au moins sur le contrôleur SATA embarqué de la carte mère. Du point de vue de la fiabilité et des performances, il est conseillé de donner un miroir (RAID1) à partir d'un SSD sous TempDB, c'est possible sur le contrôleur embarqué, mais avec la désactivation obligatoire de tous les caches pour l'écriture. Les disques SSD de bureau comme la série Intel 520, où la compression matérielle des données lors de l'écriture dans TempDB sera juste appropriée, rempliront ce rôle. Réaliser ces tâches avec système commun le stockage sur un sous-système dédié haut débit a un effet positif sur les performances du système dans son ensemble, notamment en période de pointe de charge.

Dans les cas où il est possible d'apporter la réponse la plus rapide possible des administrateurs en cas de panne, et lorsqu'il y a des tâches de calcul complexes (logistique d'entrepôt ou de transport, production dans le SCP, échanges volumétriques dans l'URBD), TempDB est placé sur RAMDrive. Une telle solution peut parfois gagner jusqu'à 4 à 12 % des performances globales du système. Certains inconvénients ne surviennent que si le serveur est redémarré : si RAMDrive ne démarre pas automatiquement, l'intervention de l'administrateur sera nécessaire pour un démarrage manuel - sinon tout le système deviendra.

Les fichiers journaux sont un autre élément important. Ils ont une fonctionnalité désagréable pour n'importe quel sous-système de disque - générer un flux presque constant de petites demandes d'écriture. Ceci est invisible aux charges moyennes, mais dégrade considérablement les performances du serveur 1C aux charges de pointe. Il est logique de déplacer le fichier journal (en particulier le fichier journal SQL) vers un volume physique distinct qui n'a pas d'exigences IOPS élevées et qui sera écrit de manière presque linéaire. Pour plus de tranquillité d'esprit, vous pouvez créer un miroir à partir de SATA / NL SAS peu coûteux et volumineux (pour le journal complet), ou de disques SSD de bureau bon marché de la même série Intel 520 (journal simple, ou journal complet, avec sa sauvegarde et son nettoyage quotidiens).

En général, on peut dire que l'arrivée des SSD dans les serveurs a ouvert de nouvelles opportunités pour augmenter les performances des serveurs de masse - en raison de la hiérarchisation des données et de la configuration intelligente des E/S des disques.

Le sous-système de disque du "serveur idéal pour 1C" ressemble à ceci :

1. Les tables de base de données sont hébergées sur RAID 10 (ou RAID 1 pour les petites bases de données) à partir de disques SSD de serveur fiables avec le contrôleur RAID matériel requis. Avec des exigences IOPS élevées, vous pouvez envisager l'option SSD PCIe. Pour les bases de données volumineuses, la mise en cache SSD des baies de disques durs est efficace. Si la configuration 1C et la structure de données utilisées ne sont pas trop exigeantes en IOPS et que le nombre d'utilisateurs est petit, une baie de disques durs SAS traditionnelle de 15 000 tr/min suffira.

2. Les fichiers d'index sont placés sur un seul SSD rapide et peu coûteux, TempDB - sur 1-2 (RAID 1) SSD ou RAMDrive.

3. Un volume dédié (un seul disque physique ou RAID-1) sur un disque dur SATA / NL SAS ou un SSD peu coûteux, ou un disque logique sur une matrice RAID, sur laquelle se trouve le système d'exploitation du serveur, est alloué aux fichiers journaux SQL (et de préférence 1C).fichiers/dossiers personnalisés.

4. Le système d'exploitation et les données utilisateur sont stockés sur RAID 1 à partir du disque dur ou du SSD.

Si l'infrastructure informatique est virtualisée, il est hautement souhaitable que SQL Server ne soit pas installé comme machine virtuelle, mais directement au serveur physique, au "bare metal". Le prix du problème est de 15 à 35% des performances du sous-système de disque (selon le matériel, les pilotes, les outils de virtualisation et la façon dont le volume est connecté). Dans un environnement de serveur SQL virtualisé, la connexion de volumes avec des tables de base de données, des fichiers d'index et TempDB à la machine virtuelle est obligatoire en mode exclusif à l'aide de l'accès direct.

Interfaces réseau

Lors de la construction de systèmes 1C: Enterprise 8 pour les petites et moyennes entreprises (jusqu'à 100-150 utilisateurs actifs en même temps), vous devez minimiser les pertes sur les opérations réseau via l'interface Ethernet. Idéalement, servez à la fois SQL Server et 1C : Enterprise 8 Application Server x64 et les sessions utilisateur 1C dans Remote Desktop avec un serveur physique. Controversée du point de vue de la tolérance aux pannes, une telle recommandation permet d'exploiter au maximum le matériel et les logiciels, et grâce à l'utilisation de la virtualisation, elle offre un certain niveau de sécurité et de "répétabilité de l'environnement" sur d'autres équipements .

Pourquoi exclure Ethernet de la chaîne SQL Server -> Application Server 1C : Enterprise 8 -> user session 1C : Enterprise 8 ? L'interface réseau Ethernet, avec son emballage de données dans des blocs relativement petits pour la transmission, créera toujours des retards supplémentaires : à la fois lors de l'emballage/déballage du trafic, et pendant la transmission elle-même (latence élevée). Dans 1C : Enterprise 8, des quantités assez importantes de données sont transférées pour être traitées et affichées tout au long de la chaîne, dans certaines situations - dans les deux sens. Lors du transfert de données directement d'un processus à un autre au sein de la RAM du serveur (sur un serveur sans virtualisation), ou via une interface réseau virtuelle (au sein du même serveur physique, avec de bons adaptateurs réseau de serveur avec le transfert de blocs de RAM entre VM), les délais sont beaucoup plus bas. Les serveurs modernes à deux processeurs avec une grande RAM et un sous-système de disque sur SSD vous permettent de servir confortablement des bases de données 1C pour 100 à 150 utilisateurs actifs.

Si pour les bases de données chargées l'utilisation de plusieurs hôtes physiques est inévitable, il est conseillé de connecter tous les serveurs via Ethernet 10Gb. Ou au moins 2 à 4 connexions Ethernet 1 Gb agrégées avec TCP/IP accéléré matériellement (TCP/IP Offloader) et prise en charge de la virtualisation matérielle.

Surtout des pertes de performances sur Port Ethernet les décisions budgétaires en pâtissent. Ce n'est un secret pour personne que les adaptateurs réseau 1 Go qui sont soudés sur la plupart des cartes mères de serveur ne sont pas conçus pour gérer un trafic réseau important. Même si la carte possède 2 ou 3 ports GbE, ils sont généralement implémentés sur des puces de bureau. Suffisantes à gérer, elles introduisent une surcharge de communication réseau supplémentaire, en particulier dans un environnement virtualisé. L'ensemble du processus de transfert de données via une telle puce est assuré au détriment des ressources du processeur, de la RAM et de la charge sur les bus internes. De telles puces ne fournissent aucune accélération de la transmission du trafic IP, chaque paquet Ethernet reçu et transmis nécessite une interruption distincte pour le processeur. Perte de performance dans un environnement virtualisé interface réseau peut atteindre 25-30%. Le plus désagréable est que la surcharge de l'interface réseau par les outils de surveillance peut être négligée. Le processeur central est bourré pour cela, et s'il ne fonctionne pas, il est inactif, en attente d'une réponse de la carte réseau. Il est souhaitable d'exclure les ports des puces de bureau du flux de données dans les environnements virtualisés, en les laissant pour les tâches de gestion des serveurs. Pour un trafic réseau intensif, vous devez ajouter un carte réseau sur le chipset du serveur.

Tolérance aux pannes ou temps d'arrêt acceptable ?

Les discussions sur les performances des serveurs s'accompagnent presque toujours de débats sur leur fiabilité. Fournir une tolérance aux pannes nécessite toujours des coûts supplémentaires, en particulier lors de la prise en charge de processus de production continus. Sans minimiser le rôle et la place de 1C, on peut dire que la plupart de ses utilisateurs résolvent le dilemme « performance / fiabilité » sur différents plans : pour le premier ils se battent avec l'optimisation des solutions matérielles, pour le second - avec l'organisation de processus et procédures. Lorsque les applications sont modérément critiques, l'objectif principal du maintien de la disponibilité n'est pas sur l'équipement de protection individuelle pour les serveurs, mais sur la minimisation des temps d'arrêt de l'infrastructure globale.

Bien entendu, pour les entreprises avec un nombre relativement important d'utilisateurs connectés simultanément (25-150) et plaçant toutes les applications sur un seul serveur, il est impératif d'utiliser des alimentations sans interruption, des alimentations redondantes pour les serveurs eux-mêmes, des paniers de disques remplaçables à chaud et matrices RAID de secours. Mais aucune quantité de matériel ne peut remplacer les sauvegardes programmées des données elles-mêmes. Disposant d'une sauvegarde quotidienne (plus précisément, nocturne) et d'un fichier opérationnel avec journal Full SQL, vous pouvez restaurer complètement la base de données 1C dans un délai relativement court.

Le temps d'arrêt autorisé du système central 1C pour les petites et moyennes entreprises est de 1 à 2 accidents par mois, d'une durée de 1 à 4 heures. En fait, c'est une énorme marge de temps - si vous êtes prêt à récupérer à l'avance. Un préalable un redémarrage rapide est la présence d'images de tous les serveurs virtuels et physiques sous la forme d'une VM sur un stockage / volume séparé - pour restaurer la partie infrastructure elle-même sur le serveur de sauvegarde. Une sauvegarde quotidienne (ainsi qu'hebdomadaire et à la fin de la période) sur un autre périphérique physique et un journal Full SQL est nécessaire dans les cas où la perte de données « depuis le début de la journée de travail » est critique et difficile à récupérer manuellement. Si vous avez un équipement de remplacement, vous pouvez conserver dans les 1-2 heures pour restaurer l'opérabilité dans son ensemble, mais avec des performances inférieures. Eh bien, lorsqu'une disponibilité 24 × 7 est requise, les tâches principales seront la sélection de l'architecture appropriée, de l'équipement avec un nombre minimum de points de défaillance et des technologies de clustering à part entière. Mais c'est une histoire complètement différente.

Article original : http://ko.com.ua/proektirovanie_servera_pod_1s_66779

Avec l'aimable autorisation de l'éditeur de la revue "Computer Review"

Les versions 8.2 et 8.3 de la plate-forme 1C : Enterprise sont considérées comme une application standard pour les tâches de comptabilité et de gestion d'entreprise. Une large gamme de solutions appliquées a été développée pour les entreprises publiques et privées. En introduisant sa propre infrastructure d'information, chaque chef ou responsable informatique de l'entreprise se demande quel type de serveur est nécessaire pour "1C". Le problème est compliqué par le fait que l'achat d'équipements nécessite des coûts financiers importants et que toutes les entreprises ne peuvent pas se permettre de choisir des configurations haut de gamme.

Nous avons recueilli les recommandations des principaux fabricants de matériel (HP, Dell, IBM) et des développeurs du produit logiciel 1C 8.3 afin que nos clients puissent acheter de manière rentable le serveur requis. L'infrastructure réseau optimale peut être obtenue avec n'importe quel système d'exploitation, mais les capacités du matériel jouent un rôle plus important à cet égard.

Critères de sélection du serveur

La plate-forme 1C peut nécessiter des ressources matérielles importantes de la part du serveur. Si le budget de l'entreprise est illimité, ce qui arrive rarement, vous pouvez sans hésiter prendre des plates-formes de dernières générations, remplir tous les paniers de disques, les emplacements de RAM et exiger de l'informaticien le fonctionnement ininterrompu du système. Choisir des équipements avec des fonds limités nécessite une approche plus équilibrée. Pour comprendre quel serveur pour "1C" sera capable de faire face à cela, il est nécessaire d'analyser soigneusement la structure des charges de calcul. S'ils sont connus à l'avance, il sera beaucoup plus facile de concevoir une solution toute faite.

Lors du choix d'un serveur pour 1C (8.2 ; 8.3), ils sont guidés par les points suivants :

• le nombre d'opérateurs effectuant simultanément la saisie et le reporting des données ;
• la possibilité de sélectionner des serveurs physiques distincts pour SQL et l'application 1C ;
• volumes de traitement de données prévus ;
• structure d'équilibrage de charge dans l'architecture client-serveur

Choix du processeur et de la RAM

Le calcul de la fréquence, du nombre requis de cœurs de processeur et de la quantité de RAM est la première et la plus importante étape. Pour envisager plusieurs options, nous choisirons un serveur pour "1C" en tenant compte du personnel de l'entreprise.

Petite organisation (jusqu'à 15 employés). Avec un petit nombre d'utilisateurs, la taille de la base de données ne dépasse généralement pas 2 Go et le programme 1C est installé sous la forme d'une version de fichier sur les machines clientes. Dans le même temps, le système d'exploitation a besoin de 4 à 6 Go et 4 Go supplémentaires sont alloués au cache de fichiers système. La répartition de la charge processeur est la suivante :

• 2 noyaux - pour les utilisateurs de systèmes d'exploitation et de terminaux ;
• 1 cœur - pour le serveur d'applications 1C ;
• 1 cœur - pour la base de données SQL.

Les machines d'entrée de gamme avec un seul processeur quadricœur peuvent gérer cette tâche. Ceux-ci peuvent être à la fois des serveurs rack et tour. Cette dernière option est préférable, car elle ne nécessite pas l'attribution d'une salle séparée pour la salle des serveurs.

Organisation moyenne (jusqu'à 40 employés). Avec un tel nombre d'utilisateurs, les développeurs de 1C recommandent d'utiliser le mode terminal d'accès à l'application. La taille des bases de données peut atteindre 4 Go. Pour une telle charge, vous avez besoin d'au moins deux processeurs pour 4 à 6 cœurs. La quantité optimale de RAM sera de 16 à 64 Go, car au moins 700 Mo doivent être alloués à chaque utilisateur. On pense que la solution d'application 1C, dans laquelle la machine client s'exécute, nécessite 240 à 480 Mo, et 200 à 220 Mo supplémentaires sont alloués aux applications bureautiques.

Avec autant de processus, il est recommandé d'utiliser une machine de niveau intermédiaire avec virtualisation ou deux serveurs physiques. L'un d'eux sera utilisé pour l'accès au terminal, et l'autre pour SQL. Il est préférable d'implémenter le serveur d'applications 1C sur la première machine, voire d'allouer un système monoprocesseur séparé pour cela. La configuration requise est sélectionnée dans chaque cas spécifique sur la base de l'analyse du temps processeur.

Grande organisation (plus de 40 employés). La configuration matérielle de base dans ce cas se composera de trois serveurs physiques :

• Terminal,
• SGBD,
• "1C".

Avec un tel nombre d'employés, les volumes de base de données dépassent souvent 4 Go, et il est recommandé d'allouer au moins la même quantité de RAM pour le cache système. 4 Go supplémentaires seront utilisés par le système d'exploitation, et environ 8 Go seront nécessaires pour les applications 1C. Ainsi, vous avez besoin d'au moins 16 Go de RAM.

Pour ces tâches, des serveurs à deux processeurs prenant en charge Intel Xeon E5-2600 ou supérieur sont sélectionnés. Si le nombre d'employés ne dépasse pas 50 personnes, une seule machine peut être laissée pour l'accès au terminal et les applications 1C. Cependant, compte tenu des perspectives de croissance de l'entreprise, il est préférable de prévoir un serveur distinct pour chaque tâche. Si le nombre de personnes impliquées approche les 100 employés, vous devez déployer un cluster de deux machines pour 1C et en laisser une pour le reste des tâches.

Choisir un sous-système de disque

Les performances du serveur dépendent directement du sous-système de disque. Lorsque les applications 1C sont en cours d'exécution, les opérations de lecture et d'écriture de données sont effectuées avec une intensité élevée. La plupart des plaintes concernant les performances du serveur sont liées au verrouillage de la table lorsqu'un grand nombre d'utilisateurs y accèdent en même temps.

La tâche de choisir un serveur pour 1C comprend la surveillance du sous-système de disque, ce qui vous permet de trouver l'équilibre optimal entre performances et fiabilité. Un facteur extrêmement important affectant les performances est sa capacité à effectuer un certain nombre d'opérations de lecture/écriture par seconde (IOPS). Si la base de données fait jusqu'à 300 Mo et que le nombre d'utilisateurs 1C est jusqu'à 6 personnes, ce paramètre est de 400 à 600. Si le nombre d'utilisateurs du serveur atteint 100, alors l'IOPS sera de 18 000. Le taux de streaming est d'une importance secondaire.

Pour chaque type de disque dur, des vitesses de lecture/écriture sont définies :

• SATA - 100/80 ;
• SAS - 240/220 ;
• SSD - 35 000/8 600.

Cela montre que les disques SSD sont les mieux adaptés aux serveurs de base de données 1C. Le principal facteur limitant leur utilisation est leur coût élevé. Par conséquent, les disques SAS sont également utilisés pour réduire le budget. Pour stocker des données critiques, y compris 1C, les disques durs sont combinés en matrices RAID de différents niveaux, et la redondance qui leur est inhérente doit être incluse dans le calcul des performances du serveur.

Lors de la conception d'une solution, la résilience du système joue un rôle important. Pour cela, le matériel et Logiciel... Les serveurs sont équipés de blocs d'alimentation remplaçables à chaud et de cages de disques, et utilisent un onduleur pour une alimentation électrique ininterrompue. La sécurité des données passe par leur sauvegarde. Un fichier journal est créé au moins une fois par jour, ce qui permet de récupérer les informations en cas de panne du système.

Vous pouvez trouver le serveur requis et le configurer pour 1C sur le site Web. Nos experts vous aideront à résoudre ce problème. Pour obtenir des conseils, contactez-les par téléphone ou contactez le responsable dans le chat.

Version client-serveur du travail- une des options pour le système 1C : Enterprise 8.

La version client-serveur du travail est destinée à être utilisée dans des groupes de travail ou dans toute l'entreprise. Il est implémenté sur la base d'une architecture client-serveur à trois niveaux.

L'architecture client-serveur divise l'ensemble du système de travail en trois parties différentes, interagissant d'une certaine manière les unes avec les autres :

Le programme en cours d'exécution pour l'utilisateur (application cliente) interagit avec le cluster de serveurs 1C: Enterprise 8, et le cluster, si nécessaire, adresse le serveur de base de données.

En même temps, physiquement, le cluster de serveurs 1C: Enterprise 8 et le serveur de base de données peuvent être situés à la fois sur le même ordinateur ou sur des ordinateurs différents. Cela permet à l'administrateur d'équilibrer la charge entre les serveurs selon les besoins.

L'utilisation d'un cluster de serveurs 1C : Enterprise 8 permet de concentrer sur celui-ci l'exécution des traitements de données les plus volumineux. Par exemple, lors de l'exécution de requêtes même très complexes, le programme exécuté pour l'utilisateur ne recevra que la sélection dont il a besoin et tous les traitements intermédiaires seront effectués sur le serveur. Augmenter la capacité d'un cluster de serveurs est généralement beaucoup plus facile que de mettre à niveau l'ensemble du parc de machines clientes.

Un autre aspect important de l'utilisation d'une architecture à 3 niveaux est la facilité d'administration et la rationalisation de l'accès des utilisateurs à l'infobase. Dans cette option, l'utilisateur n'a pas besoin de connaître l'emplacement physique de la configuration ou de la base de données. Tous les accès sont effectués via le cluster de serveurs 1C: Enterprise 8. Lors de l'accès à une infobase particulière, l'utilisateur doit spécifier uniquement le nom du cluster et le nom de l'infobase, et le système demande respectivement le nom et le mot de passe de l'utilisateur.

1C : Enterprise 8 utilise les capacités du système de gestion de base de données pour une récupération efficace des informations :

• le mécanisme de requête est axé sur la maximisation de l'utilisation du SGBD pour effectuer des calculs et établir des rapports,
• la visualisation de grandes listes dynamiques est fournie sans effectuer un grand nombre d'appels à la base de données ; en même temps, l'utilisateur se voit offrir des opportunités recherche efficace, ainsi que les paramètres de sélection et de tri.

Le déploiement et l'administration de l'option client/serveur sont simples. Par exemple, la base de données est créée directement lors du lancement du configurateur (le même que pour la version fichier).

Applications clientes

Le travail dans la version client-serveur est possible à la fois directement avec le cluster et via le serveur Web. Cependant, dans le cas d'une connexion directe au cluster, le client lourd et le client léger utilisent le protocole TCP/IP. Lors de la connexion via un serveur Web, le client léger et le client Web utilisent le protocole HTTP ou HTTPS.

Cluster de serveurs

Le cluster de serveurs 1C: Enterprise 8 est le composant principal de la plate-forme qui assure l'interaction entre les utilisateurs et le système de gestion de base de données dans une version client-serveur du travail. La présence d'un cluster permet d'assurer un fonctionnement ininterrompu, tolérant aux pannes et compétitif d'un grand nombre d'utilisateurs avec des bases d'informations importantes.

Serveur de base de données

Les éléments suivants peuvent être utilisés comme serveur de base de données :

Administration du cluster de serveurs

La livraison de la plateforme comprend un ensemble d'outils divers qui permettent à l'administrateur de gérer la composition du cluster, les infobases et la connexion des utilisateurs.

Exécution des fonctionnalités de base sur le serveur

Tout le travail avec les objets d'application, la lecture et l'écriture de la base de données est effectuée uniquement sur le serveur. La fonctionnalité des formulaires et de l'interface de commande est également implémentée sur le serveur.

Le serveur prépare les données du formulaire, organise les éléments, écrit les données du formulaire après les modifications. Le client affiche un formulaire déjà préparé sur le serveur, la saisie des données et les appels au serveur sont effectués pour enregistrer les données saisies et les autres actions nécessaires.

De même, l'interface de commande est formée sur le serveur et affichée sur le client. De plus, les rapports sont entièrement générés sur le serveur et affichés sur le client.

Dans le même temps, les mécanismes de la plate-forme visent à minimiser la quantité de données transmises à l'ordinateur client. Par exemple, les données de liste, sections tabulaires et les rapports sont envoyés depuis le serveur non pas immédiatement, mais au fur et à mesure que l'utilisateur les visualise.

Le serveur exécute :

• Requêtes de base de données,
• Enregistrement de données,
• Réalisation de documents,
• Divers calculs,
• Exécution des traitements,
• Formation de rapports,
• Préparation des formulaires pour l'affichage.

Le client exécute :

• Réception et ouverture des formulaires,
• Affichage des formulaires,
• "Communication" avec l'utilisateur (avertissements, questions...),
• De petits calculs dans des formulaires qui demandent une réponse rapide (par exemple, multiplier le prix par la quantité),
• Travailler avec des fichiers locaux,
• Travailler avec du matériel commercial.

Utilisation du langage embarqué sur le client

Vous pouvez gérer la fonctionnalité des formulaires non seulement sur le serveur, mais également sur le client. Le langage embarqué est pris en charge sur le client. Il est utilisé dans les cas où il est nécessaire d'effectuer des calculs liés au formulaire affiché à l'écran, par exemple, pour calculer rapidement (sans contacter le serveur) le montant d'une ligne de document en fonction du prix et de la quantité ; poser une question à l'utilisateur et traiter la réponse ; lire le fichier de système de fichiers ordinateur et l'envoyer au serveur.

Cependant, le fonctionnement du langage embarqué sur le client est strictement limité. Les procédures client dans les modules sont explicitement séparées des procédures serveur et elles utilisent un ensemble limité du modèle objet du langage intégré.

Le travail direct avec la base de données n'est pas autorisé sur le client. Il n'est pas permis de travailler directement avec des objets appliqués, par exemple, ces types de langage intégré ne sont pas disponibles comme DirectoryObject.<имя> ... L'utilisation de requêtes n'est pas autorisée. Si vous devez appeler des actions avec des données dans le code client, vous devez appeler des procédures serveur qui accéderont déjà aux données.