{"id":35800,"date":"2019-10-31T22:06:24","date_gmt":"2019-10-31T19:06:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/dizajn-virtualizovannogo-tsod\/"},"modified":"2019-10-31T22:06:24","modified_gmt":"2019-10-31T19:06:24","slug":"dizajn-virtualizovannogo-tsod","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","title":{"rendered":"Conception de centre de donn\u00e9es virtualis\u00e9","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Conception
\n
\nIntroduction<\/b><\/p>\n

Un syst\u00e8me d'information, du point de vue de l'utilisateur, est bien d\u00e9fini dans la norme GOST RV 51987 comme un \u00ab syst\u00e8me automatis\u00e9 dont le r\u00e9sultat est la pr\u00e9sentation d'informations de sortie pour une utilisation ult\u00e9rieure \u00bb. En consid\u00e9rant la structure interne, toute SI est essentiellement un syst\u00e8me d'algorithmes interconnect\u00e9s r\u00e9alis\u00e9s en code. Au sens large de la th\u00e8se de Turing et Church, un algorithme (et donc une SI) effectue la transformation d'un ensemble de donn\u00e9es d'entr\u00e9e en un ensemble de donn\u00e9es de sortie.
\nOn peut m\u00eame dire que la transformation des donn\u00e9es d'entr\u00e9e est le sens d'existence d'un syst\u00e8me d'information. Par cons\u00e9quent, la valeur de la SI et de l'ensemble du complexe SI est d\u00e9termin\u00e9e par la valeur des donn\u00e9es d'entr\u00e9e et de sortie.
\nSur cette base, la conception doit commencer par les donn\u00e9es, adaptant l'architecture et les m\u00e9thodes \u00e0 la structure et \u00e0 la signification des donn\u00e9es.<\/p>\n

Donn\u00e9es stock\u00e9es<\/b>
\nUne \u00e9tape cl\u00e9 dans la pr\u00e9paration \u00e0 la conception est l'obtention des caract\u00e9ristiques de tous les ensembles de donn\u00e9es pr\u00e9vus pour le traitement et le stockage. Ces caract\u00e9ristiques incluent :
\n \u2014 Volume des donn\u00e9es;
\n \u2014 Informations sur le cycle de vie des donn\u00e9es (croissance des nouvelles donn\u00e9es, dur\u00e9e de vie, traitement des donn\u00e9es obsol\u00e8tes);
\n \u2014 Classification des donn\u00e9es en fonction de leur impact sur le principal business de l'entreprise (sur les trois axes de la confidentialit\u00e9, de l'int\u00e9grit\u00e9 et de la disponibilit\u00e9), accompagn\u00e9e d'indicateurs financiers (par exemple, le co\u00fbt de la perte de donn\u00e9es sur la derni\u00e8re heure);
\n \u2014 G\u00e9ographie du traitement des donn\u00e9es (emplacement physique des syst\u00e8mes de traitement);
\n \u2014 Exigences des r\u00e9gulateurs pour chaque classe de donn\u00e9es (par exemple, la loi FZ-152, PCI DSS).<\/p>\n

<\/a><\/noindex><\/p>\n

Syst\u00e8mes d'information<\/b><\/p>\n

Les donn\u00e9es ne sont pas seulement stock\u00e9es mais \u00e9galement trait\u00e9es (transform\u00e9es) par les syst\u00e8mes d'information. L'\u00e9tape suivante apr\u00e8s l'obtention des caract\u00e9ristiques des donn\u00e9es est l'inventaire le plus complet possible des syst\u00e8mes d'information, de leurs caract\u00e9ristiques architecturales, de leurs interd\u00e9pendances et de leurs exigences en mati\u00e8re d'infrastructure en unit\u00e9s conditionnelles pour quatre types de ressources :
\n \u2014 Puissance de calcul du processeur;
\n \u2014 Volume de m\u00e9moire vive;
\n \u2014 Exigences en mati\u00e8re de capacit\u00e9 et de performance du syst\u00e8me de stockage de donn\u00e9es;
\n \u2014 Exigences du r\u00e9seau de transmission de donn\u00e9es (canaux externes, canaux entre les composants de la SI).
\nLes exigences doivent \u00eatre d\u00e9finies pour chaque service\/microservice au sein du syst\u00e8me d'information.
\nIl est \u00e9galement n\u00e9cessaire de noter l'obligation d'avoir des donn\u00e9es sur l'impact du syst\u00e8me d'information sur l'activit\u00e9 principale de l'entreprise sous forme de co\u00fbts d'arr\u00eat du syst\u00e8me d'information (roubles par heure).<\/p>\n

Mod\u00e8le de menace<\/b><\/p>\n

Il est imp\u00e9ratif d'avoir un mod\u00e8le formel des menaces dont on pr\u00e9voit de prot\u00e9ger les donn\u00e9es\/services. Ce mod\u00e8le de menace doit inclure non seulement des aspects de confidentialit\u00e9, mais aussi d'int\u00e9grit\u00e9 et de disponibilit\u00e9. Par exemple :
\n \u2014 Panne d'un serveur physique ;
\n \u2014 Panne d'un commutateur top-of-the-rack ;
\n \u2014 Rupture de la liaison optique entre les centres de donn\u00e9es ;
\n \u2014 Panne compl\u00e8te d'un syst\u00e8me de stockage de donn\u00e9es op\u00e9rationnel.
\nDans certains cas, des mod\u00e8les de menace sont \u00e9crits non seulement pour les composants d'infrastructure, mais aussi pour des syst\u00e8mes d'information sp\u00e9cifiques ou leurs composants, comme la d\u00e9faillance d'une base de donn\u00e9es avec destruction logique de la structure des donn\u00e9es.
\nToutes les d\u00e9cisions dans le cadre du projet pour se prot\u00e9ger contre une menace non d\u00e9crite sont superflues.<\/p>\n

Exigences des r\u00e9gulateurs<\/b><\/p>\n

Si les donn\u00e9es trait\u00e9es sont soumises \u00e0 des r\u00e8gles sp\u00e9ciales fix\u00e9es par les r\u00e9gulateurs, des informations sur les ensembles de donn\u00e9es et les r\u00e8gles de traitement\/de stockage sont imp\u00e9rativement n\u00e9cessaires.<\/p>\n

Indicateurs cibles RPO\/RTO<\/b><\/p>\n

La conception de tout type de protection n\u00e9cessite des indicateurs de perte de donn\u00e9es cible et de temps de restauration cible du service pour chacune des menaces d\u00e9crites.
\nId\u00e9alement, les indicateurs RPO et RTO devraient avoir des co\u00fbts associ\u00e9s \u00e0 la perte de donn\u00e9es et \u00e0 l'arr\u00eat par unit\u00e9 de temps.<\/p>\n

\"Conception
\n
\nS\u00e9paration en pools de ressources<\/b><\/p>\n

Apr\u00e8s avoir collect\u00e9 toutes les informations de base, la premi\u00e8re \u00e9tape consiste \u00e0 grouper les ensembles de donn\u00e9es et les syst\u00e8mes d'information en pools, en fonction des mod\u00e8les de menace et des exigences des r\u00e9gulateurs. Le type de s\u00e9paration des diff\u00e9rents pools est d\u00e9termin\u00e9 : par logiciel au niveau du syst\u00e8me d'exploitation ou physiquement.
\nExemples :
\n \u2014 Le p\u00e9rim\u00e8tre traitant des donn\u00e9es personnelles est compl\u00e8tement physiquement s\u00e9par\u00e9 des autres syst\u00e8mes ;
\n \u2014 Les sauvegardes sont conserv\u00e9es sur un syst\u00e8me de stockage distinct.<\/p>\n

D'autre part, les pools peuvent avoir une ind\u00e9pendance incompl\u00e8te, par exemple, deux pools de ressources de calcul (puissance de traitement + m\u00e9moire vive) peuvent partager un pool de stockage de donn\u00e9es commun et un pool de ressources de transmission de donn\u00e9es commun.<\/p>\n

Puissance de traitement<\/b><\/p>\n

\"Conception
\n
\nLes besoins abstraits en puissance de calcul des centres de donn\u00e9es virtualis\u00e9s sont mesur\u00e9s en nombre de processeurs virtuels (vCPU) et en coefficient de leur consolidation sur les processeurs physiques (pCPU). Dans ce cas pr\u00e9cis, 1 pCPU = 1 c\u0153ur physique de processeur (sans tenir compte du Hyper-Threading). Le nombre de vCPU est totalis\u00e9 sur tous les pools de ressources d\u00e9finis (chacun pouvant avoir son propre coefficient de consolidation).
\nLe coefficient de consolidation pour les syst\u00e8mes charg\u00e9s est obtenu empiriquement, \u00e0 partir de l'infrastructure existante, ou lors d'une installation pilote et de tests de charge. Pour les syst\u00e8mes non charg\u00e9s, des \u00ab best practices \u00bb sont appliqu\u00e9es. En particulier, VMware indique un coefficient moyen de 8:1.<\/p>\n

M\u00e9moire vive<\/b><\/p>\n

Le besoin total en m\u00e9moire vive est obtenu par simple addition. L'utilisation de la surallocation de m\u00e9moire vive n'est pas recommand\u00e9e.<\/p>\n

Ressources de stockage<\/b><\/p>\n

Les exigences en mati\u00e8re de ressources de stockage sont obtenues par simple addition de tous les pools en termes de volume et de performance.
\nLes exigences de performance sont exprim\u00e9es en IOPS en combinaison avec le ratio moyen de lecture\/\u00e9criture et, si n\u00e9cessaire, la latence de r\u00e9ponse maximale.
\nLes exigences en mati\u00e8re de qualit\u00e9 de service (QoS) doivent \u00eatre sp\u00e9cifiquement indiqu\u00e9es pour des pools ou syst\u00e8mes particuliers.<\/p>\n

Ressources de r\u00e9seau de donn\u00e9es<\/b><\/p>\n

Les exigences en mati\u00e8re de r\u00e9seau de donn\u00e9es sont obtenues par simple addition de tous les pools de bande passante.
\nLes exigences en mati\u00e8re de qualit\u00e9 de service (QoS) et de latences (RTT) pour des pools ou syst\u00e8mes particuliers doivent \u00eatre sp\u00e9cifiquement indiqu\u00e9es.
\nDans le cadre des exigences relatives aux ressources r\u00e9seau, il convient \u00e9galement d'indiquer les exigences en mati\u00e8re d'isolation et\/ou de cryptage du trafic r\u00e9seau et les m\u00e9canismes pr\u00e9f\u00e9r\u00e9s (802.1q, IPSec, etc.).<\/p>\n

Choix de l'architecture<\/b><\/p>\n

Dans le cadre de ce guide, aucun autre choix que l'architecture x86 et 100 % de virtualisation des serveurs n'est consid\u00e9r\u00e9. Ainsi, le choix de l'architecture du sous-syst\u00e8me de calcul se r\u00e9duit \u00e0 celui de la plateforme de virtualisation des serveurs, au facteur de forme des serveurs et aux exigences g\u00e9n\u00e9rales en mati\u00e8re de configuration des serveurs.<\/p>\n

Un point cl\u00e9 dans le choix est la certitude d'utiliser une approche classique de s\u00e9paration des fonctions de traitement, de stockage et de transmission des donn\u00e9es, ou convergente.<\/p>\n

Architecture classique<\/i> implique l'utilisation de syst\u00e8mes de stockage et de transmission de donn\u00e9es externes intelligents, tandis que les serveurs n'apportent au pool commun de ressources physiques que la puissance du processeur et la m\u00e9moire vive. Dans le cas extr\u00eame, les serveurs deviennent compl\u00e8tement anonymes, ne poss\u00e9dant ni disques durs, ni m\u00eame d'identifiant syst\u00e8me. Dans ce cas, le d\u00e9marrage du syst\u00e8me d'exploitation ou de l'hyperviseur s'effectue \u00e0 partir de supports flash int\u00e9gr\u00e9s ou d'un syst\u00e8me de stockage externe (boot from SAN).
\nDans l'architecture classique, le choix entre les modules (blade) et les serveurs en rack (rack) se fait principalement selon les principes suivants :
\n \u2014 Efficacit\u00e9 \u00e9conomique (en moyenne, les serveurs en rack sont moins chers);
\n \u2014 Densit\u00e9 de calcul (plus \u00e9lev\u00e9e pour les blades);
\n \u2014 Consommation d'\u00e9nergie et \u00e9mission de chaleur (plus \u00e9lev\u00e9e par unit\u00e9 pour les blades);
\n \u2014 Scalabilit\u00e9 et gestionabilit\u00e9 (les blades n\u00e9cessitent g\u00e9n\u00e9ralement moins d'efforts lors de grandes installations);
\n \u2014 Utilisation de cartes d'extension (choix tr\u00e8s limit\u00e9 pour les blades).
\nArchitecture convergente<\/i> (\u00e9galement connue sous le nom de hyperconvergente<\/i>) combine les fonctions de traitement et de stockage des donn\u00e9es, ce qui entra\u00eene l'utilisation de disques locaux dans les serveurs et, par cons\u00e9quent, l'abandon du format classique des blades. Pour les syst\u00e8mes convergents, on utilise soit des serveurs en rack, soit des syst\u00e8mes en cluster qui combinent plusieurs serveurs blades et des disques locaux dans un seul bo\u00eetier.<\/p>\n

CPU \/ M\u00e9moire <\/b><\/p>\n

Pour le calcul correct de la configuration, il est n\u00e9cessaire de comprendre le type de charge pour l'environnement ou chacun des clusters ind\u00e9pendants.
\nLimit\u00e9 par le CPU<\/i> \u2013 un environnement limit\u00e9 par la puissance de traitement du processeur. L'augmentation de la m\u00e9moire vive ne changera rien en termes de performance (nombre de VM sur le serveur).
\nLimit\u00e9 par la m\u00e9moire<\/i> \u2013 un environnement limit\u00e9 par la m\u00e9moire vive. Une plus grande quantit\u00e9 de m\u00e9moire sur le serveur permet de lancer plus de VM sur le serveur.
\nGB \/ MHz (GB \/ pCPU) \u2013 le rapport moyen de consommation de la m\u00e9moire vive et de la puissance de traitement pour cette charge sp\u00e9cifique. Peut \u00eatre utilis\u00e9 pour le calcul du volume de m\u00e9moire n\u00e9cessaire pour une performance donn\u00e9e et vice versa. <\/p>\n

Calcul de la configuration du serveur<\/b><\/p>\n

\"Conception
\n
\nTout d'abord, il est n\u00e9cessaire de d\u00e9finir tous les types de charge et de d\u00e9cider d'int\u00e9grer ou de diviser diff\u00e9rents pools de calcul sur divers clusters.
\nEnsuite, pour chaque cluster d\u00e9fini, on d\u00e9termine le rapport GB \/ MHz en fonction de la charge connue \u00e0 l'avance. Si la charge n'est pas connue \u00e0 l'avance, mais qu'on a une id\u00e9e approximative du niveau de charge du processeur, on peut utiliser les coefficients standards vCPU:pCPU pour traduire les exigences des pools en physiques. <\/p>\n

Pour chaque cluster, on divise la somme des exigences de vCPU par le coefficient :
\nvCPUtotal \/ vCPU:pCPU = pCPUtotal \u2013 nombre requis de c\u0153urs physiques
\npCPUtotal \/ 1.25 = pCPUht \u2013 nombre de c\u0153urs ajust\u00e9 pour le Hyper-Threading
\nSupposons qu'il soit n\u00e9cessaire de calculer un cluster avec 190 c\u0153urs \/ 3,5 To de RAM. Dans ce cas, nous prenons une charge cible de 50 % de capacit\u00e9 processeur et 75 % pour la m\u00e9moire vive.<\/p>\n

pCPU<\/b>
\n190
\nUtilisation du CPU<\/b>
\n50%<\/p>\n

Mem<\/b>
\n3500
\nUtilisation de la m\u00e9moire<\/b>
\n75%<\/p>\n

Socket<\/b>
\nNoyau<\/b>
\nSrv \/ CPU<\/b>
\nSrv M\u00e9moire<\/b>
\nSrv \/ M\u00e9moire<\/b><\/p>\n

2
\n6
\n25,3
\n128
\n36,5<\/p>\n

2
\n8
\n19,0
\n192
\n24,3<\/p>\n

2
\n10
\n15,2
\n256
\n18,2<\/p>\n

2
\n14
\n10,9
\n384
\n12,2<\/p>\n

2
\n18
\n8,4
\n512
\n9,1<\/p>\n

Dans ce cas, nous utilisons toujours un arrondi au nombre entier sup\u00e9rieur (=ROUNDUP(A1;0)).
\nLe tableau montre clairement que plusieurs configurations de serveurs sont \u00e9quilibr\u00e9es par rapport aux indicateurs cibles :
\n \u2014 26 serveurs 2*6c \/ 192 Go
\n \u2014 19 serveurs 2*10c \/ 256 Go
\n \u2014 10 serveurs 2*18c \/ 512 Go <\/p>\n

Le choix entre ces configurations doit ensuite se faire en fonction de facteurs suppl\u00e9mentaires, tels que le package thermique et le refroidissement disponible, les serveurs d\u00e9j\u00e0 utilis\u00e9s, ou le co\u00fbt.<\/p>\n

Caract\u00e9ristiques du choix de la configuration du serveur<\/b><\/p>\n

Machines virtuelles larges. En cas de n\u00e9cessit\u00e9 de d\u00e9ployer des machines virtuelles larges (comparables \u00e0 1 n\u0153ud NUMA et plus), il est recommand\u00e9, dans la mesure du possible, de choisir un serveur avec une configuration permettant \u00e0 ces VM de rester dans la limite du n\u0153ud NUMA. Avec un grand nombre de VM larges, il existe un risque de fragmentation des ressources du cluster, et dans ce cas, on choisit des serveurs permettant de d\u00e9ployer les VM larges aussi dens\u00e9ment que possible.<\/p>\n

Taille du domaine de d\u00e9faillance unique.<\/b> <\/p>\n

Le choix de la taille du serveur se fait \u00e9galement sur le principe de minimisation du domaine de d\u00e9faillance unique. Par exemple, lors du choix entre :
\n \u2014 3 x 4*10c \/ 512 Go
\n \u2014 6 x 2*10c \/ 256 Go
\nSi toutes choses sont \u00e9gales par ailleurs, il faut choisir la deuxi\u00e8me option, car en cas de d\u00e9faillance (ou de maintenance) d'un serveur, ce ne sont pas 33 % des ressources du cluster qui sont perdues, mais 17 %. De m\u00eame, le nombre de VM et de services impact\u00e9s par l'incident est r\u00e9duit de moiti\u00e9.<\/p>\n

Calcul du stockage classique en fonction des performances<\/b><\/p>\n

\"Conception
\n
\nLe stockage classique est toujours calcul\u00e9 selon le pire sc\u00e9nario, en excluant l'impact du cache m\u00e9moire et l'optimisation des op\u00e9rations.
\nNous prenons comme indicateurs de r\u00e9f\u00e9rence la performance m\u00e9canique du disque (IOPSdisk) :
\n \u2014 7.2k \u2013 75 IOPS
\n \u2014 10k \u2013 125 IOPS
\n \u2014 15k \u2013 175 IOPS<\/p>\n

Le nombre de disques dans le pool de disques est calcul\u00e9 avec la formule suivante : = TotalIOPS * ( RW + (1 \u2013 RW) * RAIDPen) \/ IOPSdisk<\/i>. O\u00f9 :
\n \u2014 TotalIOPS<\/i> \u2013 performance totale requise en IOPS du pool de disques
\n \u2014 RW<\/i> \u2013 pourcentage des op\u00e9rations de lecture
\n \u2014 RAIDpen<\/i> \u2013 p\u00e9nalit\u00e9 RAID pour le niveau RAID choisi<\/p>\n

En savoir plus sur les dispositifs RAID et la p\u00e9nalit\u00e9 RAID ici — Performance du stockage. Partie un.<\/a><\/noindex> et Performance du stockage. Partie deux.<\/a><\/noindex> et Performance du stockage. Partie trois.<\/a><\/noindex><\/p>\n

En fonction du nombre de disques calcul\u00e9s, nous \u00e9valuons les diff\u00e9rentes options r\u00e9pondant aux exigences en mati\u00e8re de capacit\u00e9 de stockage, y compris des options avec stockage hi\u00e9rarchique.
\nLe calcul des syst\u00e8mes utilisant des SSD comme niveau de stockage est trait\u00e9 s\u00e9par\u00e9ment.
\nParticularit\u00e9s du calcul des syst\u00e8mes avec Flash Cache
\n<\/b><\/p>\n

Flash Cache<\/i> \u2013 terme g\u00e9n\u00e9rique pour toutes les technologies propri\u00e9taires utilisant la m\u00e9moire flash comme cache de deuxi\u00e8me niveau. Lors de l'utilisation du cache flash, le stockage est g\u00e9n\u00e9ralement calcul\u00e9 pour prendre en charge la charge \u00e9tablie des disques magn\u00e9tiques, tandis que la charge de pointe est g\u00e9r\u00e9e par le cache.
\nIl est \u00e9galement n\u00e9cessaire de comprendre le profil de charge et le degr\u00e9 de localisation des acc\u00e8s aux blocs des volumes de stockage. Le cache flash est une technologie pour les charges avec une haute localisation des requ\u00eates, et pratiquement inapplicable pour les volumes avec une charge uniforme (comme par exemple pour les syst\u00e8mes d'analyse). <\/p>\n

Calcul des syst\u00e8mes hybrides low-end \/ mid-range<\/b><\/p>\n

Les syst\u00e8mes hybrides de classe inf\u00e9rieure et interm\u00e9diaire utilisent un stockage \u00e0 plusieurs niveaux avec un d\u00e9placement des donn\u00e9es entre les niveaux selon un calendrier. Dans ce cas, la taille de bloc de stockage \u00e0 plusieurs niveaux des meilleurs mod\u00e8les atteint 256 Mo. Ces caract\u00e9ristiques ne permettent pas de consid\u00e9rer la technologie de stockage \u00e0 plusieurs niveaux comme une technologie d'am\u00e9lioration des performances, comme beaucoup l'estiment \u00e0 tort. Le stockage \u00e0 plusieurs niveaux dans les syst\u00e8mes de classe inf\u00e9rieure et interm\u00e9diaire est une technologie d'optimisation des co\u00fbts de stockage pour des syst\u00e8mes pr\u00e9sentant une charge in\u00e9gale.<\/p>\n

Pour le stockage hi\u00e9rarchique, nous calculons d'abord les performances du niveau sup\u00e9rieur, tandis que le niveau inf\u00e9rieur n'est consid\u00e9r\u00e9 que comme contribuant \u00e0 la capacit\u00e9 de stockage manquante. Pour un syst\u00e8me hybride \u00e0 plusieurs niveaux, l'utilisation de la technologie de cache flash pour le pool hi\u00e9rarchique est indispensable afin de compenser la chute de performance des donn\u00e9es soudainement sollicit\u00e9es du niveau inf\u00e9rieur.<\/p>\n

Utilisation de SSD dans le pool de disques hi\u00e9rarchique<\/b><\/p>\n

\"Conception
\n
\nL'utilisation de SSD dans le pool de disques hi\u00e9rarchique varie en fonction des sp\u00e9cificit\u00e9s des algorithmes de cache flash de ce fabricant.
\nLa pratique g\u00e9n\u00e9rale de la politique de stockage pour un pool de disques avec niveau SSD est \u2014 SSD first.
\nRead Only Flash Cache.<\/i> Pour le cache flash en mode lecture seule, le niveau de stockage sur SSD appara\u00eet lors d'une localisation significative des op\u00e9rations d'\u00e9criture, ind\u00e9pendamment du cache.
\nCache Flash en Lecture \/ \u00c9criture.<\/i> Dans le cas d'un cache flash en \u00e9criture, un maximum de taille de cache est d'abord \u00e9tabli, et le niveau de stockage sur SSD n'appara\u00eet que lorsque la taille du cache est insuffisante pour traiter toute la charge localis\u00e9e.
\nLa performance du SSD et du cache est toujours calcul\u00e9e en fonction des recommandations du fabricant, mais toujours pour le pire des cas.
\n
Source : habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0441 \u0442\u043e\u0447\u043a\u0438 \u0437\u0440\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f \u0445\u043e\u0440\u043e\u0448\u043e \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u044f\u0435\u0442\u0441\u044f \u0432 \u0413\u041e\u0421\u0422 \u0420\u0412 51987 \u2014 \u00ab\u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0430\u0442\u043e\u043c \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043a\u043e\u0442\u043e\u0440\u043e\u0439 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0432\u044b\u0445\u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0434\u043b\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0435\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f\u00bb. \u0415\u0441\u043b\u0438 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0442\u044c \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u044e\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443, \u0442\u043e \u043f\u043e \u0441\u0443\u0442\u0438 \u043b\u044e\u0431\u0430\u044f \u0418\u0421 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439 \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0445 \u0432 \u043a\u043e\u0434\u0435 \u0432\u0437\u0430\u0438\u043c\u043e\u0441\u0432\u044f\u0437\u0430\u043d\u043d\u044b\u0445 \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c\u043e\u0432. \u0412 \u0448\u0438\u0440\u043e\u043a\u043e\u043c \u043f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0438 \u0442\u0435\u0437\u0438\u0441\u0430 \u0422\u044c\u044e\u0440\u0438\u043d\u0433\u0430-\u0427\u0435\u0440\u0447\u0430 \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c (\u0430 \u0441\u043b-\u043d\u043e \u0418\u0421) \u043e\u0441\u0443\u0449\u0435\u0441\u0442\u0432\u043b\u044f\u0435\u0442 \u0442\u0440\u0430\u043d\u0441\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044e \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0430 \u0432\u0445\u043e\u0434\u043d\u044b\u0445 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26806,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35800","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Conception d'un Data Center Virtualis\u00e9 | ProHoster","description":"Introduction au Syst\u00e8me d'information en point.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0438\u0437\u0430\u0439\u043d \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u043e\u0433\u043e \u0426\u041e\u0414 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0441 \u0442\u043e\u0447\u043a\u0438.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:06:24+00:00","article:modified_time":"2019-10-31T19:06:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35800","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 00:48:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:06:24","updated":"2026-01-22 00:48:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/35800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=35800"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/35800\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/26806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=35800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=35800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=35800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}