Le GIGABYTE R181-2A0 est un serveur 1U basé sur les processeurs Intel Xeon Scalable de deuxième génération . Ces processeurs offrent de nombreux avantages, notamment la prise en charge de la mémoire Optane DC, des fréquences CPU plus élevées et les performances accrues qui en découlent, une vitesse DDR4 supérieure et la technologie Intel Deep Learning Boost. Ce serveur est extrêmement flexible et convient parfaitement aux applications connectées à un stockage partagé ou aux cas d'utilisation HPC.
D'un point de vue matériel, nous avons mentionné les processeurs, le serveur dispose de 24 emplacements DIMM, de trois emplacements d'extension PCIe et de deux emplacements mezzanine OCP Gen3, et de blocs d'alimentation redondants en platine 1200W 80 Plus. Pour le stockage, GIGABYTE opte pour SAS ou SATA plutôt que de lancer NVMe dans tout. Fondamentalement, tout le monde ne veut pas ou n'a pas besoin de NVMe ou du coût qui y est associé. Et pour ces clients, ce serveur fait l'affaire.
Nous avons fait un aperçu vidéo ici:
Notre configuration particulière comprend deux processeurs Intel 8280, 384 To de mémoire et un SSD NVMe Memblaze PBlaze5 C926 edgecard.
Spécifications du GIGABYTE R181-2A0
| Facteur de forme | 1U |
| Dimensions (LxHxP, mm) | 438 x 43.5 x 730 |
| Carte mère | MR91-FS0 |
| Processeur | Processeurs Intel Xeon Scalable et Intel Xeon Scalable de 2e génération Processeur Intel Xeon Platinum, processeur Intel Xeon Gold, processeur Intel Xeon Silver et processeur Intel Xeon Bronze TDP du processeur jusqu'à 205 W |
| Douille | 2 prises LGA 3647 P |
| Chipset | Jeu de puces Intel C621 Express |
| Mémoire | 24 emplacements DIMM Mémoire DDR4 prise en charge uniquement Architecture mémoire à 6 canaux Modules RDIMM jusqu'à 64 Go pris en charge Modules LRDIMM jusqu'à 128 Go pris en charge Prend en charge la mémoire persistante Intel Optane DC (DCPMM) Modules 1.2 V : 2933 2666/2400 2133/XNUMX XNUMX/XNUMX XNUMX MHz |
| LAN | 2 ports LAN 1 Gb/s (Intel I350-AM2) 1 réseau local de gestion 10/100/1000 |
| Stockage | 10 baies HDD/SSD 2.5″ SATA/SAS remplaçables à chaud La configuration par défaut prend en charge : 10 disques SATA ou 2 disques SATA 8 disques SAS La carte SAS est requise pour la prise en charge des périphériques SAS |
| SATA | 2 x 7 broches SATA III 6 Gb/s avec SATA DOM pris en charge En utilisant la broche_8 ou un câble externe pour la fonction d'alimentation |
| SAS | Pris en charge via une carte SAS complémentaire |
| RAID | Intel SATA RAID 0/1/10/5 |
| Slots d'extension | Carte de montage CRS1021 : – 2 x emplacements PCIe x8 (Gen3 x8), demi-longueur profil bas Carte de montage CRS1015 : – 1 emplacement PCIe x16 (Gen3 x16), demi-longueur profil bas 2 emplacements mezzanine OCP – PCIe Gen3 x16 – Type1, P1, P2, P3, P4, K2, K3 |
| E / S internes | 2 connecteurs d'alimentation 4 connecteurs SlimSAS 2 connecteurs SATA 7 broches 2 x en-têtes de ventilateur CPU 1 connecteur USB 3.0 1 x en-tête TPM 1 connecteur VROC 1 x en-tête de panneau avant 1 x en-tête de carte de fond de panier HDD 1 connecteur IPMB 1 x cavalier CMOS transparent 1 x cavalier de récupération du BIOS |
| Front I / O | 1 x USB 3.0 1 x bouton d'alimentation avec LED 1 x bouton d'identification avec LED 1 bouton x Reset 1 bouton NMI 2 LED d'activité LAN 1 LED d'activité du disque dur 1 x voyant d'état du système |
| I / O arrière | 2 x USB 3.0 1 x VGA 1 port COM (type RJ45) 2 x RJ45 1x MLAN 1 x bouton d'identification avec LED |
| E/S de fond de panier | 10 ports SATA/SAS Bande passante : SATAIII 6Gb/s ou SAS 12Gb/s par port 2 ports U.2 (réservés) Bande passante : PCIe Gen3 x4 par port (réservé) |
| TPM | 1 x en-tête TPM avec interface LPC Kit TPM2.0 en option : CTM000 |
| Alimentation | 2 blocs d'alimentation redondants de 1200 XNUMX W 80 PLUS Platinum Entrée AC: – 100-240V~/ 12-7A, 50-60Hz Entrée DC: – 240 Vcc/ 6A DC Sortie: – Max 1000W/100-240V~ +12V/80.5A +12Vsb/ 3A – Entrée max 1200W/ 200-240V~ ou 240Vdc +12V/97A +12Vsb/ 3A |
| Poids | 13 kg |
| Ventilateurs du système | 8x40x40x56mm (23'000rpm) |
| Propriétés de fonctionnement | Température de fonctionnement: 10 ° C à 35 ° C Humidité de fonctionnement: 8-80% (sans condensation) Température hors fonctionnement : -40°C à 60°C Humidité hors fonctionnement : 20 % à 95 % (sans condensation) |
Conception et fabrication du GIGABYTE R181-2A0
Comme indiqué, le GIGABYTE R181-2A0 a un facteur de forme 1U. À l'avant du serveur se trouvent dix baies de lecteur SATA/SAS de 2.5 pouces. Sur la gauche se trouvent des voyants lumineux, un bouton d'alimentation, un bouton d'identification, un bouton de réinitialisation, un bouton NMI et un port USB 3.0.
L'arrière du serveur comporte deux blocs d'alimentation sur la gauche, un port VGA, deux ports USB 3.0, deux ports RJ45, un port COM, un port MLAN, un bouton d'identification et les trois logements d'extension à profil bas près du haut ainsi que les deux emplacements OCP près du bas.
En ouvrant le serveur, nous voyons immédiatement les processeurs et la RAM au milieu. Cela permet aux utilisateurs d'accéder facilement aux cartes de montage et aux connecteurs d'extension dont ils ont besoin. Nous avons installé un HBA FC 16 Go double port pour se connecter au stockage partagé, une carte réseau 4 GbE double port Mellanox Connect-X 25 ainsi que notre SSD Memblaze PBlaze5.
Direction
Le serveur GIGABYTE R181-2A0 dispose de son propre logiciel de gestion à distance GSM, mais peut également exploiter la plateforme AMI MegaRAC SP-X pour la gestion du BMC. Nous utiliserons MegaRAC pour ce test. Pour une analyse plus approfondie d'AMI MegaRAC SP-X dans un serveur GIGABYTE, consultez notre test du serveur GIGABYTE R272-Z32 AMD EPYC Rome.
À partir de l'écran de gestion principal, vous pouvez afficher des statistiques rapides sur la page d'accueil et voir plusieurs onglets principaux sur le côté gauche, notamment : tableau de bord, capteur, inventaire du système, informations FRU, journaux et rapports, paramètres, télécommande, redirection d'image, contrôle de l'alimentation, et Entretien. La première page est le tableau de bord. Ici, on peut facilement voir le temps de disponibilité du BMC, les désaffirmations en attente, les journaux d'accès et le nombre de problèmes, la surveillance des capteurs, les emplacements de lecteur et le nombre d'événements qu'ils ont eu au cours des dernières 24 heures ainsi que des 30 derniers jours.
Une fois lancée, la console distante donne aux utilisateurs un accès à distance au système d'exploitation du serveur, qui dans notre exemple est un écran de chargement Linux. Les fenêtres de console à distance sont un outil inestimable dans un centre de données où vous souhaitez un contrôle local sans avoir à transporter un moniteur, un clavier et un chariot de secours pour le faire. Visible en haut à droite de la fenêtre se trouve la fonction d'image de CD qui vous permet de monter des ISO à partir de votre système local pour qu'ils soient accessibles à distance sur le serveur pour le chargement du logiciel.
Grâce à l'onglet de maintenance, les utilisateurs peuvent trouver des informations sur le BIOS et des informations sur le micrologiciel.
Performances du GIGABYTE R181-2A0
Configuration GIGABYTE R181-2A0 :
- 2 processeurs Intel 8280 (28 cœurs, 2.7 GHz)
- 12 x 32 Go 2933 6 MHz, XNUMX modules DIMM par CPU
- 1 SSD Memblaze PBlaze6.4 C5 NVMe de 926 To
- VMware ESXi 6.7u3
- CentOS 7 (1908)
Performances du serveur SQL
Le protocole de test Microsoft SQL Server OLTP de StorageReview utilise la version actuelle du Transaction Processing Performance Council's Benchmark C (TPC-C), une référence de traitement des transactions en ligne qui simule les activités trouvées dans des environnements d'application complexes. Le benchmark TPC-C est plus proche que les benchmarks de performances synthétiques pour évaluer les forces de performance et les goulots d'étranglement de l'infrastructure de stockage dans les environnements de base de données.
Chaque machine virtuelle SQL Server est configurée avec deux vDisks : un volume de 100 Go pour le démarrage et un volume de 500 Go pour la base de données et les fichiers journaux. Du point de vue des ressources système, nous avons configuré chaque machine virtuelle avec 16 vCPU, 64 Go de DRAM et exploité le contrôleur LSI Logic SAS SCSI. Alors que nos charges de travail Sysbench testées précédemment saturaient la plate-forme à la fois en termes d'E/S de stockage et de capacité, le test SQL recherche les performances de latence.
Ce test utilise SQL Server 2014 s'exécutant sur des machines virtuelles invitées Windows Server 2012 R2 et est souligné par Dell Benchmark Factory for Databases. Alors que notre utilisation traditionnelle de cette référence a été de tester de grandes bases de données à l'échelle 3,000 1,500 sur un stockage local ou partagé, dans cette itération, nous nous concentrons sur la répartition uniforme de quatre bases de données à l'échelle XNUMX XNUMX sur nos serveurs.
Configuration des tests SQL Server (par machine virtuelle)
- Windows Server 2012 R2
- Empreinte de stockage : 600 Go alloués, 500 Go utilisés
- SQL Server 2014
-
- Taille de la base de données : échelle 1,500 XNUMX
- Charge de client virtuel : 15,000 XNUMX
- Mémoire tampon : 48 Go
- Durée du test : 3 heures
- 2.5 heures de préconditionnement
- Période d'échantillonnage de 30 minutes
Pour notre benchmark transactionnel SQL Server, le GIGABYTE avait un score global de 12,643.8 3,160.1 TPS avec des machines virtuelles individuelles allant de 3,161.5 XNUMX TPS à XNUMX XNUMX TPS.
Pour la latence moyenne de SQL Server, le serveur avait un score global de 2.3 ms avec des machines virtuelles allant de 1 ms à 3 ms.
Performances Sysbench MySQL
Notre premier benchmark d'application de stockage local consiste en une base de données Percona MySQL OLTP mesurée via SysBench. Ce test mesure également le TPS moyen (transactions par seconde), la latence moyenne et la latence moyenne au 99e centile.
Chaque machine virtuelle Sysbench est configurée avec trois vDisks : un pour le démarrage (~92 Go), un avec la base de données prédéfinie (~447 Go) et le troisième pour la base de données testée (270 Go). Du point de vue des ressources système, nous avons configuré chaque machine virtuelle avec 16 vCPU, 60 Go de DRAM et exploité le contrôleur LSI Logic SAS SCSI.
Configuration des tests Sysbench (par machine virtuelle)
- CentOS 6.3 64 bits
- Percona XtraDB 5.5.30-rel30.1
-
- Tableaux de base de données : 100
- Taille de la base de données : 10,000,000 XNUMX XNUMX
- Threads de base de données : 32
- Mémoire tampon : 24 Go
- Durée du test : 3 heures
- 2 heures de préconditionnement 32 fils
- 1 heure 32 fils
Avec l'OLTP Sysbench, le GIGABYTE R181-2A0 avait un score global de 11,096.4 1,375 TPS avec des machines virtuelles individuelles fonctionnant entre 1,422.72 XNUMX TPS et XNUMX XNUMX TPS.
Pour la latence moyenne de Sysbench, le serveur avait un score global de 23.1 ms avec des machines virtuelles individuelles fonctionnant de 22.5 ms à 23.3 ms.
Pour notre pire scénario de latence (99e centile), le GIGABYTE avait un score global de 40.3 ms avec des machines virtuelles individuelles fonctionnant de 40.2 ms à 40.4 ms.
Analyse de la charge de travail VDBench
Lorsqu'il s'agit de comparer les baies de stockage, les tests d'application sont les meilleurs et les tests synthétiques viennent en deuxième position. Bien qu'ils ne soient pas une représentation parfaite des charges de travail réelles, les tests synthétiques aident à référencer les périphériques de stockage avec un facteur de répétabilité qui facilite la comparaison de pommes à pommes entre des solutions concurrentes. Ces charges de travail offrent une gamme de profils de test différents allant des tests « aux quatre coins », des tests de taille de transfert de base de données communs, ainsi que des captures de traces à partir de différents environnements VDI. Tous ces tests exploitent le générateur de charge de travail vdBench commun, avec un moteur de script pour automatiser et capturer les résultats sur un grand cluster de test de calcul. Cela nous permet de répéter les mêmes charges de travail sur une large gamme de périphériques de stockage, y compris les baies flash et les périphériques de stockage individuels.
Profils:
- Lecture aléatoire 4K : 100 % de lecture, 128 threads, 0-120 % d'iorate
- Écriture aléatoire 4K : 100 % d'écriture, 64 threads, 0-120 % de vitesse
- Lecture séquentielle 64K : 100 % de lecture, 16 threads, 0-120 % d'iorate
- Écriture séquentielle 64K : 100 % d'écriture, 8 threads, 0-120 % d'iorate
- Base de données synthétique : SQL et Oracle
- Traces de clone complet et de clone lié VDI
Avec une lecture 4K aléatoire, le GIGABYTE R181-2A0 a démarré fort avec un pic à 706,664 178.6 IOPS avec une latence de XNUMX µs.
Pour l'écriture aléatoire 4K, le serveur a démarré à 58,406 33.9 IOPS à seulement 100 µs et est resté en dessous de 561,280 µs jusqu'à près de son pic qui s'est avéré être 213.3 XNUMX IOPS et XNUMX µs.
Ensuite, les charges de travail séquentielles où nous avons examiné 64k. Pour 64K de lecture, le GIGABYTE a culminé à 82,271 5.1 IOPS ou 387.4 Go/s avec une latence de XNUMX µs.
Les écritures séquentielles de 64K ont vu le serveur atteindre environ 43K IOPS ou environ 2.7 Go/s à une latence de 182 µs avant d'en laisser tomber.
Notre prochaine série de tests concerne nos charges de travail SQL : SQL, SQL 90-10 et SQL 80-20. En commençant par SQL, le serveur a culminé à 220,712 143 IOPS avec une latence de XNUMX µs.
Pour SQL 90-10, nous avons constaté des performances de pointe de 230,152 137 IOPS avec une latence de XNUMX µs.
SQL 80-20 a poursuivi ses bonnes performances avec un pic de 229,724 136 IOPS avec XNUMX µs de latence.
Viennent ensuite nos charges de travail Oracle : Oracle, Oracle 90-10 et Oracle 80-20. À partir d'Oracle, le serveur a culminé à 246,191 142 IOPS avec une latence de XNUMX µs.
Avec Oracle 90-10, le GIGABYTE a pu atteindre 172,642 125.5 IOPS avec une latence de XNUMX µs.
Oracle 80-20, la dernière référence Oracle, a vu le serveur atteindre un pic de 178,108 121 IOPS à XNUMX µs pour la latence.
Ensuite, nous sommes passés à notre test de clone VDI, Full et Linked. Pour le démarrage VDI Full Clone (FC), le GIGABYTE R181-2A0 a culminé à 196,719 174 IOPS avec une latence de XNUMX µs.
Pour la connexion initiale VDI FC, le serveur a culminé à 150,518 190 IOPS avec XNUMX µs de latence.
VDI FC Monday Login a vu le serveur culminer à 94,813 161.3 IOPS avec une latence de XNUMX µs.
En passant au démarrage VDI Linked Clone (LC), le GIGABYTE a pu atteindre 89,269 177.4 IOPS avec une latence de XNUMX µs.
Avec VDI LC Initial Login, le serveur a atteint 50,860 148 IOPS à XNUMX µs.
Enfin, VDI LC Monday Login a vu le GIGABYTE atteindre 75,850 201.3 IOPS avec une latence de XNUMX µs.
Conclusion
ConclusionLe GIGABYTE R181-2A0 est un autre serveur construit autour des processeurs évolutifs Xeon de deuxième génération d'Intel et de tous les avantages de ces processeurs. En plus d'être centré sur Intel Xeon Scalable, ce serveur 1U est très flexible. Bien que seulement 1U, le serveur peut héberger deux processeurs évolutifs Intel Xeon, 24 modules DIMM de RAM, 10 baies de lecteur 2.5 pouces pour disques SATA ou SAS, et dispose de trois emplacements d'extension PCIe et de deux emplacements mezzanine OCP. Le serveur est destiné à être un bourreau de travail applicatif connecté à un stockage partagé, ou peut-être à des cas d'utilisation HPC.
Pour les performances, nous avons exécuté à la fois notre analyse de la charge de travail des applications et nos tests VDBench. Bien que les baies de lecteur avant ne prennent pas en charge NVMe, les connecteurs d'extension le font et nous avons ajouté un lecteur NVMe pour maximiser le potentiel de performances du serveur. Dans notre benchmark SQL Server, le serveur avait des scores globaux de 12,642.8 2.3 TPS et une latence moyenne de 11,810 ms. Pour Sysbench, nous avons constaté des scores cumulés de 23.1 40.3 TPS, une latence moyenne de XNUMX ms et une latence dans le pire des cas de XNUMX ms.
Pour VDbench, le petit serveur a continué à atteindre d'assez bons chiffres, les points forts étant 707K IOPS pour la lecture 4K, 561K IOPS pour l'écriture 4K, 5.1 Go/s pour la lecture 64K et 2.7 Go/s pour l'écriture 64K. Lors de nos tests SQL, le R181-2A0 a pu atteindre des pics de 221 230 IOPS, 90 10 IOPS en SQL 230-80 et 20 246 IOPS en SQL 173-90. Pour Oracle, les chiffres étaient de 10 178 IOPS, 80 20 IOPS dans Oracle 100-197 et 151 XNUMX IOPS dans Oracle XNUMX-XNUMX. Lors de nos tests de clone VDI, le nombre a commencé à s'estomper mais est resté supérieur à XNUMX XNUMX IOPS dans le démarrage VDI FC (XNUMX XNUMX IOPS) et la connexion initiale VDI FC (XNUMX XNUMX IOPS).
Pour ceux qui recherchent une grande flexibilité dans un format compact, ils n'ont pas besoin de chercher plus loin que le GIGABYTE R181-2A0.
Amazon