Il s’agit d’un mythe assez courant dans le domaine du matériel serveur. En pratique, des solutions hyperconvergées (lorsque tout est en un) sont nécessaires pour de nombreuses choses. Historiquement, les premières architectures ont été développées par Amazon et Google pour leurs services. L’idée était alors de réaliser une ferme informatique à partir de nœuds identiques, chacun possédant ses propres disques. Tout cela était uni par un logiciel formant système (hyperviseur) et divisé en machines virtuelles. L'objectif principal est un minimum d'effort pour entretenir un nœud et un minimum de problèmes lors de la mise à l'échelle : il suffit d'acheter mille ou deux autres serveurs identiques et de les connecter à proximité. En pratique, il s'agit de cas isolés, et bien plus souvent on parle d'un plus petit nombre de nœuds et d'une architecture légèrement différente.
Mais l'avantage reste le même : une incroyable facilité de mise à l'échelle et de gestion. L'inconvénient est que différentes tâches consomment des ressources de différentes manières et qu'à certains endroits, il y aura beaucoup de disques locaux, à d'autres, il y aura peu de RAM, etc., c'est-à-dire que pour différents types de tâches, l'utilisation des ressources diminuera.
Il s'avère que vous payez 10 à 15 % de plus pour la facilité d'installation. C'est ce qui a déclenché le mythe du titre. Nous avons longuement cherché où la technologie serait appliquée de manière optimale et nous l’avons trouvé. Le fait est que Cisco ne disposait pas de ses propres systèmes de stockage, mais souhaitait un marché de serveurs complet. Et ils ont créé Cisco Hyperflex, une solution avec stockage local sur les nœuds.
Et cela s’est soudainement avéré être une très bonne solution pour la sauvegarde des centres de données (Disaster Recovery). Je vais vous dire pourquoi et comment maintenant. Et je vais vous montrer les tests de cluster.
Là où c'est nécessaire
L'hyperconvergence est :
- Transfert de disques vers des nœuds de calcul.
- Intégration complète du sous-système de stockage avec le sous-système de virtualisation.
- Transfert/intégration avec le sous-système réseau.
Cette combinaison vous permet d'implémenter de nombreuses fonctionnalités du système de stockage au niveau de la virtualisation et le tout à partir d'une seule fenêtre de contrôle.
Dans notre entreprise, les projets de conception de centres de données redondants sont très demandés, et une solution hyperconvergée est souvent choisie en raison de nombreuses options de réplication (jusqu'à un metrocluster) prêtes à l'emploi.
Dans le cas des centres de données de sauvegarde, nous parlons généralement d'une installation distante sur un site à l'autre bout de la ville ou dans une autre ville. Il permet de restaurer les systèmes critiques en cas de panne partielle ou totale du data center principal. Les données de ventes y sont constamment répliquées, et cette réplication peut se faire au niveau de l'application ou au niveau du périphérique bloc (stockage).
Par conséquent, je vais maintenant parler de la conception et des tests du système, puis de quelques scénarios d'application réels avec des données d'économies.
Tests
Notre instance est composée de quatre serveurs dotés chacun de 10 disques SSD de 960 Go. Il existe un disque dédié à la mise en cache des opérations d'écriture et au stockage de la machine virtuelle de service. La solution elle-même est la quatrième version. Le premier est franchement rudimentaire (à en juger par les critiques), le second est humide, le troisième est déjà assez stable, et celui-ci peut être qualifié de version après la fin des tests bêta destinés au grand public. Lors des tests, je n'ai constaté aucun problème, tout fonctionne comme une horloge.
Changements dans la v4Un tas de bugs ont été corrigés.
Initialement, la plateforme ne pouvait fonctionner qu'avec l'hyperviseur VMware ESXi et prenait en charge un petit nombre de nœuds. De plus, le processus de déploiement ne s'est pas toujours terminé correctement, certaines étapes ont dû être redémarrées, il y a eu des problèmes avec la mise à jour à partir des anciennes versions, les données dans l'interface graphique n'étaient pas toujours affichées correctement (même si je ne suis toujours pas satisfait de l'affichage des graphiques de performances ), des problèmes surgissaient parfois à l'interface avec la virtualisation .
Désormais, tous les problèmes de l'enfance ont été résolus, HyperFlex peut gérer à la fois ESXi et Hyper-V, et il est également possible de :
- Création d'un cluster étendu.
- Création d'un cluster pour bureaux sans utiliser Fabric Interconnect, de deux à quatre nœuds (nous achetons uniquement des serveurs).
- Capacité à travailler avec des systèmes de stockage externes.
- Prise en charge des conteneurs et de Kubernetes.
- Création de zones de disponibilité.
- Intégration avec VMware SRM si la fonctionnalité intégrée n'est pas satisfaisante.
L'architecture n'est pas très différente des solutions de ses principaux concurrents : ils n'ont pas créé de vélo. Le tout fonctionne sur la plateforme de virtualisation VMware ou Hyper-V. Le matériel est hébergé sur des serveurs propriétaires Cisco UCS. Il y a ceux qui détestent la plateforme pour la relative complexité de la configuration initiale, beaucoup de boutons, un système de modèles et de dépendances non trivial, mais il y a aussi ceux qui ont appris le Zen, s'inspirent de l'idée et ne veulent plus pour travailler avec d'autres serveurs.
Nous considérerons la solution pour VMware, car la solution a été créée à l'origine pour lui et a plus de fonctionnalités ; Hyper-V a été ajouté en cours de route afin de suivre le rythme des concurrents et de répondre aux attentes du marché.
Il existe un cluster de serveurs rempli de disques. Il existe des disques pour le stockage des données (SSD ou HDD - selon vos goûts et vos besoins), il existe un disque SSD pour la mise en cache. Lors de l'écriture des données dans la banque de données, les données sont enregistrées sur la couche de mise en cache (disque SSD dédié et RAM de la VM de service). En parallèle, un bloc de données est envoyé aux nœuds du cluster (le nombre de nœuds dépend du facteur de réplication du cluster). Après confirmation de tous les nœuds de la réussite de l'enregistrement, la confirmation de l'enregistrement est envoyée à l'hyperviseur puis à la VM. Les données enregistrées sont dédupliquées, compressées et écrites sur des disques de stockage en arrière-plan. Dans le même temps, un gros bloc est toujours écrit sur les disques de stockage et de manière séquentielle, ce qui réduit la charge sur les disques de stockage.
La déduplication et la compression sont toujours activées et ne peuvent pas être désactivées. Les données sont lues directement à partir des disques de stockage ou du cache RAM. Si une configuration hybride est utilisée, les lectures sont également mises en cache sur le SSD.
Les données ne sont pas liées à l'emplacement actuel de la machine virtuelle et sont réparties uniformément entre les nœuds. Cette approche vous permet de charger tous les disques et interfaces réseau de manière égale. Il y a un inconvénient évident : on ne peut pas réduire au maximum la latence de lecture, puisqu'il n'y a aucune garantie de disponibilité des données localement. Mais je crois que c’est un sacrifice mineur par rapport aux bénéfices reçus. De plus, les retards du réseau ont atteint des valeurs telles qu'ils n'affectent pratiquement pas le résultat global.
Un contrôleur de service spécial VM Cisco HyperFlex Data Platform, créé sur chaque nœud de stockage, est responsable de l'ensemble de la logique de fonctionnement du sous-système de disque. Dans notre configuration de VM de service, huit vCPU et 72 Go de RAM ont été alloués, ce qui n'est pas si peu. Permettez-moi de vous rappeler que l'hôte lui-même dispose de 28 cœurs physiques et de 512 Go de RAM.
La VM de service a accès aux disques physiques directement en transférant le contrôleur SAS à la VM. La communication avec l'hyperviseur s'effectue via un module spécial IOVisor, qui intercepte les opérations d'E/S, et à l'aide d'un agent qui vous permet d'envoyer des commandes à l'API de l'hyperviseur. L'agent est chargé de travailler avec les instantanés et les clones HyperFlex.
Les ressources disque sont montées dans l'hyperviseur sous forme de partages NFS ou SMB (selon le type d'hyperviseur, devinez lequel se trouve où). Et sous le capot, il s'agit d'un système de fichiers distribué qui vous permet d'ajouter des fonctionnalités de systèmes de stockage adultes à part entière : allocation de volumes dynamiques, compression et déduplication, instantanés utilisant la technologie Redirect-on-Write, réplication synchrone/asynchrone.
La VM de service permet d'accéder à l'interface de gestion WEB du sous-système HyperFlex. Il existe une intégration avec vCenter et la plupart des tâches quotidiennes peuvent être effectuées à partir de celui-ci, mais les banques de données, par exemple, sont plus pratiques à découper à partir d'une webcam séparée si vous êtes déjà passé à une interface HTML5 rapide ou si vous utilisez un client Flash à part entière. avec une intégration complète. Dans la webcam de service, vous pouvez visualiser les performances et l'état détaillé du système.
Il existe un autre type de nœuds dans un cluster : les nœuds informatiques. Il peut s'agir de serveurs rack ou lames sans disques intégrés. Ces serveurs peuvent exécuter des machines virtuelles dont les données sont stockées sur des serveurs dotés de disques. Du point de vue de l'accès aux données, il n'y a pas de différence entre les types de nœuds, car l'architecture implique une abstraction de l'emplacement physique des données. Le rapport maximum entre les nœuds de calcul et les nœuds de stockage est de 2:1.
L'utilisation de nœuds de calcul augmente la flexibilité lors de la mise à l'échelle des ressources du cluster : nous n'avons pas besoin d'acheter des nœuds supplémentaires avec des disques si nous n'avons besoin que de CPU/RAM. De plus, nous pouvons ajouter une cage à lames et économiser sur le placement en rack des serveurs.
Nous disposons ainsi d’une plateforme hyperconvergée avec les fonctionnalités suivantes :
- Jusqu'à 64 nœuds dans un cluster (jusqu'à 32 nœuds de stockage).
- Le nombre minimum de nœuds dans un cluster est de trois (deux pour un cluster Edge).
- Mécanisme de redondance des données : mise en miroir avec facteur de réplication 2 et 3.
- Cluster métropolitain.
- Réplication asynchrone de VM vers un autre cluster HyperFlex.
- Orchestration de la commutation des VM vers un centre de données distant.
- Instantanés natifs utilisant la technologie Redirect-on-Write.
- Jusqu'à 1 Po d'espace utilisable avec un facteur de réplication 3 et sans déduplication. Nous ne prenons pas en compte le facteur de réplication 2, car ce n'est pas une option pour des ventes sérieuses.
Un autre avantage considérable est la facilité de gestion et de déploiement. Toutes les complexités de configuration des serveurs UCS sont prises en charge par une VM spécialisée préparée par les ingénieurs Cisco.
Configuration du banc de test :
- 2 x Cisco UCS Fabric Interconnect 6248UP en tant que cluster de gestion et composants réseau (48 ports fonctionnant en mode Ethernet 10G/FC 16G).
- Quatre serveurs Cisco UCS HXAF240 M4.
Caractéristiques du serveur :
Processeur
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 Go DDR4-2400 4 MHz RDIMM/PC19200-4/double rang/x1.2/XNUMX V
Réseau
UCSC-MLOM-CSC-02 (VIC 1227). 2 ports Ethernet 10G
HBA de stockage
Contrôleur de passage SAS modulaire Cisco 12G
Disques de stockage
1 x SSD Intel S3520 120 Go, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 Go
Plus d'options de configurationEn plus du matériel sélectionné, les options suivantes sont actuellement disponibles :
- HXAF240c M5.
- Un ou deux processeurs allant d'Intel Silver 4110 à Intel Platinum I8260Y. Deuxième génération disponible.
- 24 emplacements mémoire, bandes de 16 Go RDIMM 2600 à 128 Go LRDIMM 2933.
- De 6 à 23 disques de données, un disque de mise en cache, un disque système et un disque de démarrage.
Disques de capacité
- HX-SD960G61X-EV 960 Go 2.5 pouces Enterprise Value 6G SATA SSD (endurance 1X) SAS 960 Go.
- HX-SD38T61X-EV 3.8 To 2.5 pouces Enterprise Value 6G SATA SSD (endurance 1X) SAS 3.8 To.
- Mise en cache des lecteurs
- HX-NVMEXPB-I375 Disque Intel Optane 375 Go 2.5 pouces, performances et endurance extrêmes.
- HX-NVMEHW-H1600* 1.6 To 2.5 pouces Ent. Perf. SSD NVMe (endurance 3X) NVMe 1.6 To.
- HX-SD400G12TX-EP 400 Go 2.5 pouces Ent. Perf. SSD SAS 12G (endurance 10X) SAS 400 Go.
- HX-SD800GBENK9** 800 Go 2.5 pouces Ent. Perf. SSD SAS SED 12G (endurance 10X) SAS 800 Go.
- HX-SD16T123X-EP SSD SAS 1.6G de 2.5 To de 12 pouces aux performances d'entreprise (endurance 3X).
Lecteurs de journaux/système
- HX-SD240GM1X-EV SSD SATA 240G de valeur entreprise de 2.5 Go de 6 pouces (nécessite une mise à niveau).
Disques de démarrage
- HX-M2-240GB 240 Go SATA M.2 SSD SATA 240 Go.
Connectez-vous au réseau via des ports Ethernet 40G, 25G ou 10G.
Le FI peut être HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Le test lui-même
Pour tester le sous-système disque, j'ai utilisé HCIBench 2.2.1. Il s'agit d'un utilitaire gratuit qui vous permet d'automatiser la création d'une charge à partir de plusieurs machines virtuelles. La charge elle-même est générée par le fio habituel.
Notre cluster est composé de quatre nœuds, facteur de réplication 3, tous les disques sont Flash.
Pour les tests, j'ai créé quatre banques de données et huit machines virtuelles. Pour les tests d'écriture, on suppose que le disque de mise en cache n'est pas plein.
Les résultats des tests sont les suivants :
100% lu 100% aléatoire
0% Lecture 100% Aléatoire
Profondeur de bloc/file d'attente
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36 ms 374348 IOPS
2.47 ms 414116 IOPS
4,86 ms 420180 IOPS
2,22 ms 57408 IOPS
3,09 ms 82744 IOPS
5,02 ms 101824 IPOS
8,75 ms 116912 IOPS
17,2 ms 118592 IOPS
8K
0,67 ms 188416 IOPS
0,93 ms 273280 IOPS
1,7 ms 299932 IOPS
2,72 ms 376,484 IOPS
5,47 ms 373,176 IOPS
3,1 ms 41148 IOPS
4,7 ms 54396 IOPS
7,09 ms 72192 IOPS
12,77 ms 80132 IOPS
16K
0,77 ms 164116 IOPS
1,12 ms 228328 IOPS
1,9 ms 268140 IOPS
3,96 ms 258480 IOPS
3,8 ms 33640 IOPS
6,97 ms 36696 IOPS
11,35 ms 45060 IOPS
32K
1,07 ms 119292 IOPS
1,79 ms 142888 IOPS
3,56 ms 143760 IOPS
7,17 ms 17810 IOPS
11,96 ms 21396 IOPS
64K
1,84 ms 69440 IOPS
3,6 ms 71008 IOPS
7,26 ms 70404 IOPS
11,37 ms 11248 IOPS
Le gras indique les valeurs au-delà desquelles il n'y a pas d'augmentation de la productivité, parfois même une dégradation est visible. Cela est dû au fait que nous sommes limités par les performances du réseau/contrôleurs/disques.
- Lecture séquentielle 4432 Mo/s.
- Écriture séquentielle 804 Mo/s.
- Si un contrôleur tombe en panne (panne d'une machine virtuelle ou d'un hôte), la baisse de performances est double.
- Si le disque de stockage tombe en panne, le prélèvement est de 1/3. La reconstruction du disque prend 5 % des ressources de chaque contrôleur.
Sur un petit bloc, on est limité par les performances du contrôleur (machine virtuelle), son CPU est chargé à 100%, et quand le bloc augmente, on est limité par la bande passante du port. 10 Gbit/s ne suffisent pas pour libérer tout le potentiel du système AllFlash. Malheureusement, les paramètres du stand de démonstration fourni ne nous permettent pas de tester le fonctionnement à 40 Gbit/s.
D'après mon impression d'après les tests et l'étude de l'architecture, grâce à l'algorithme qui place les données entre tous les hôtes, nous obtenons des performances évolutives et prévisibles, mais c'est aussi une limitation lors de la lecture, car il serait possible d'extraire davantage des disques locaux, ici, cela peut permettre d'économiser un réseau plus productif, par exemple, FI à 40 Gbit/s est disponible.
De plus, un seul disque pour la mise en cache et la déduplication peut constituer une limitation ; en fait, dans ce banc de test, nous pouvons écrire sur quatre disques SSD. Ce serait formidable de pouvoir augmenter le nombre de disques de mise en cache et voir la différence.
Utilisation réelle
Pour organiser un data center de sauvegarde, vous pouvez utiliser deux approches (nous n'envisageons pas de placer une sauvegarde sur un site distant) :
- Actif Passif. Toutes les applications sont hébergées dans le centre de données principal. La réplication est synchrone ou asynchrone. Si le centre de données principal tombe en panne, nous devons activer celui de secours. Cela peut être fait manuellement/scripts/applications d'orchestration. Ici, nous obtiendrons un RPO proportionné à la fréquence de réplication, et le RTO dépend de la réaction et des compétences de l'administrateur et de la qualité du développement/débogage du plan de commutation.
- Actif-Actif. Dans ce cas, il n'y a que réplication synchrone ; la disponibilité des centres de données est déterminée par un quorum/arbitre situé strictement sur le site tiers. RPO = 0, et RTO peut atteindre 0 (si l'application le permet) ou égal au temps de basculement d'un nœud dans un cluster de virtualisation. Au niveau de la virtualisation, un cluster étendu (Metro) est créé qui nécessite un stockage actif-actif.
Habituellement, nous constatons que les clients ont déjà implémenté une architecture avec un système de stockage classique dans le centre de données principal, nous en concevons donc une autre pour la réplication. Comme je l'ai mentionné, Cisco HyperFlex propose une réplication asynchrone et une création de cluster de virtualisation étendue. Dans le même temps, nous n'avons pas besoin d'un système de stockage dédié de niveau milieu de gamme et supérieur avec des fonctions de réplication coûteuses et un accès aux données actif-actif sur deux systèmes de stockage.
Script 1: Nous disposons d'un data center principal et de secours, d'une plateforme de virtualisation sur VMware vSphere. Tous les systèmes productifs sont situés dans le centre de données principal et la réplication des machines virtuelles est effectuée au niveau de l'hyperviseur, ce qui évitera de garder les machines virtuelles allumées dans le centre de données de sauvegarde. Nous répliquons les bases de données et les applications spéciales à l'aide d'outils intégrés et maintenons les machines virtuelles activées. Si le centre de données principal tombe en panne, nous lançons des systèmes dans le centre de données de secours. Nous pensons avoir environ 100 machines virtuelles. Pendant que le centre de données principal est opérationnel, le centre de données de secours peut exécuter des environnements de test et d'autres systèmes qui peuvent être arrêtés en cas de basculement du centre de données principal. Il est également possible que nous utilisions une réplication bidirectionnelle. D'un point de vue matériel, rien ne changera.
Dans le cas d'une architecture classique, nous installerons dans chaque data center un système de stockage hybride avec accès via FibreChannel, hiérarchisation, déduplication et compression (mais pas en ligne), 8 serveurs pour chaque site, 2 commutateurs FibreChannel et Ethernet 10G. Pour la gestion de la réplication et de la commutation dans une architecture classique, on peut utiliser des outils VMware (Réplication + SRM) ou des outils tiers, qui seront un peu moins chers et parfois plus pratiques.
La figure montre le diagramme.
Lors de l'utilisation de Cisco HyperFlex, l'architecture suivante est obtenue :
Pour HyperFlex, j'ai utilisé des serveurs avec de grosses ressources CPU/RAM, car... Une partie des ressources ira à la VM du contrôleur HyperFlex ; au niveau CPU et mémoire, j'ai même un peu reconfiguré la configuration HyperFlex pour ne pas jouer le jeu de Cisco et garantir des ressources pour les VM restantes. Mais nous pouvons abandonner les commutateurs FibreChannel et nous n'aurons pas besoin de ports Ethernet pour chaque serveur : le trafic local est commuté au sein de FI.
Le résultat a été la configuration suivante pour chaque centre de données :
Les serveurs
Serveur 8 x 1U (384 Go de RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 Go de RAM, 2 x Intel Gold 6150, 3,2 Go SSD, 10 x 6 To NL-SAS)
Espace de rangement
Système de stockage hybride avec FC Front-End (SSD 20 To, NL-SAS 130 To)
-
LAN
2 commutateurs Ethernet 10G 12 ports
-
SAN
2 x commutateur FC 32/16 Go 24 ports
2 x Cisco UCS FI 6332
Licences
VMware Ent Plus
Réplication et/ou orchestration de la commutation de VM
VMware Ent Plus
Je n'ai pas fourni de licences de logiciel de réplication pour Hyperflex, car celui-ci est disponible immédiatement pour nous.
Pour l'architecture classique, j'ai choisi un fournisseur qui s'est imposé comme un fabricant de haute qualité et peu coûteux. Pour les deux options, j'ai appliqué la remise standard pour une solution spécifique et j'ai ainsi reçu des prix réels.
La solution Cisco HyperFlex s'est avérée 13 % moins chère.
Script 2: création de deux datacenters actifs. Dans ce scénario, nous concevons un cluster étendu sur VMware.
L'architecture classique se compose de serveurs de virtualisation, d'un SAN (protocole FC) et de deux systèmes de stockage capables de lire et d'écrire sur le volume tendu entre eux. Sur chaque système de stockage nous mettons une capacité utile de stockage.
Chez HyperFlex, nous créons simplement un Stretch Cluster avec le même nombre de nœuds sur les deux sites. Dans ce cas, un facteur de réplication de 2+2 est utilisé.
Le résultat est la configuration suivante :
architecture classique
HyperFlex
Les serveurs
Serveur 16 x 1U (384 Go de RAM, 2 x Intel Gold 6132, FC HBA, 2 x NIC 10G)
16 x HX240C-M5L (512 Go de RAM, 2 x Intel Gold 6132, 1,6 To NVMe, 12 x 3,8 To SSD, VIC 1387)
Espace de rangement
2 x systèmes de stockage AllFlash (SSD de 150 To)
-
LAN
4 commutateurs Ethernet 10G 24 ports
-
SAN
4 x commutateur FC 32/16 Go 24 ports
4 x Cisco UCS FI 6332
Licences
VMware Ent Plus
VMware Ent Plus
Dans tous les calculs, je n'ai pas pris en compte l'infrastructure réseau, les coûts du data center, etc. : ils seront les mêmes pour l'architecture classique et pour la solution HyperFlex.
En termes de coût, HyperFlex s'est avéré 5 % plus cher. Il convient de noter ici qu'en termes de ressources CPU/RAM, j'avais un biais pour Cisco, car dans la configuration, j'ai rempli uniformément les canaux du contrôleur de mémoire. Le coût est légèrement plus élevé, mais pas d'un ordre de grandeur, ce qui indique clairement que l'hyperconvergence n'est pas nécessairement un « jouet pour les riches », mais peut rivaliser avec l'approche standard de construction d'un centre de données. Cela peut également intéresser ceux qui disposent déjà de serveurs Cisco UCS et de l'infrastructure correspondante.
Parmi les avantages, on retrouve l'absence de coûts d'administration du SAN et des systèmes de stockage, la compression et la déduplication en ligne, un point d'entrée unique pour le support (virtualisation, serveurs, ce sont aussi des systèmes de stockage), un gain d'espace (mais pas dans tous les scénarios), opération simplifiante.
En ce qui concerne le support, vous l'obtenez ici auprès d'un seul fournisseur - Cisco. À en juger par mon expérience avec les serveurs Cisco UCS, je l'aime bien ; je n'ai pas eu besoin de l'ouvrir sur HyperFlex, tout a fonctionné de la même manière. Les ingénieurs réagissent rapidement et peuvent résoudre non seulement des problèmes typiques, mais également des cas extrêmes complexes. Parfois, je me tourne vers eux avec des questions : « Est-ce possible de faire ça, merde ? ou "J'ai configuré quelque chose ici et cela ne veut pas fonctionner. Aide!" - ils y trouveront patiemment le guide nécessaire et leur indiqueront les actions correctes ; ils ne répondront pas : « Nous ne résolvons que les problèmes matériels ».
références
- Mon E-mail - [email protected]
Source: habr.com