{"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\/pt\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","title":{"rendered":"Design do Data Center Virtualizado","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Design
\n
\nIntrodu\u00e7\u00e3o<\/b><\/p>\n

Um sistema de informa\u00e7\u00e3o do ponto de vista do usu\u00e1rio \u00e9 bem definido na norma GOST R\u0412 51987 \u2014 \"sistema automatizado, cujo resultado da opera\u00e7\u00e3o \u00e9 a apresenta\u00e7\u00e3o de informa\u00e7\u00f5es para uso subsequente\". Se considerarmos a estrutura interna, qualquer SI \u00e9, na ess\u00eancia, um sistema de algoritmos interconectados implementados em c\u00f3digo. Em um sentido amplo, o teorema de Turing-Church afirma que um algoritmo (e, consequentemente, um SI) realiza a transforma\u00e7\u00e3o de um conjunto de dados de entrada em um conjunto de dados de sa\u00edda.
\nPode-se at\u00e9 afirmar que o sentido da exist\u00eancia de um sistema de informa\u00e7\u00e3o reside na transforma\u00e7\u00e3o de dados de entrada. Portanto, o valor do SI e de todo o complexo de SIS \u00e9 determinado pelo valor dos dados de entrada e sa\u00edda.
\nDiante disso, o projeto deve come\u00e7ar e ter como base os dados, ajustando a arquitetura e os m\u00e9todos \u00e0 estrutura e import\u00e2ncia dos dados.<\/p>\n

Dados Armazenados<\/b>
\nUma etapa crucial na prepara\u00e7\u00e3o para o projeto \u00e9 a obten\u00e7\u00e3o das caracter\u00edsticas de todos os conjuntos de dados planejados para processamento e armazenamento. Essas caracter\u00edsticas incluem:
\n \u2014 Volume de dados;
\n \u2014 Informa\u00e7\u00f5es sobre o ciclo de vida dos dados (crescimento de novos dados, tempo de vida, tratamento de dados obsoletos);
\n \u2014 Classifica\u00e7\u00e3o dos dados do ponto de vista do impacto nos neg\u00f3cios principais da empresa (na tr\u00edade de confidencialidade, integridade, disponibilidade) juntamente com m\u00e9tricas financeiras (por exemplo, custo da perda de dados \u00faltima hora);
\n \u2014 Geografia do processamento de dados (localiza\u00e7\u00e3o f\u00edsica dos sistemas de processamento);
\n \u2014 Requisitos regulat\u00f3rios para cada classe de dados (por exemplo, Lei Federal-152, PCI DSS).<\/p>\n

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

Sistemas de Informa\u00e7\u00e3o<\/b><\/p>\n

Os dados n\u00e3o s\u00e3o apenas armazenados, mas tamb\u00e9m processados (transformados) por sistemas de informa\u00e7\u00e3o. O pr\u00f3ximo passo ap\u00f3s obter as caracter\u00edsticas dos dados \u00e9 realizar um invent\u00e1rio o mais completo poss\u00edvel dos sistemas de informa\u00e7\u00e3o, suas caracter\u00edsticas arquitet\u00f4nicas, interdepend\u00eancias e requisitos de infraestrutura em unidades condicionais para quatro tipos de recursos:
\n \u2014 Poder computacional do processador;
\n \u2014 Volume de mem\u00f3ria RAM;
\n \u2014 Requisitos para o volume e desempenho do sistema de armazenamento de dados;
\n \u2014 Requisitos para a rede de transmiss\u00e3o de dados (canais externos, canais entre componentes do SI).
\nOs requisitos devem ser aplicados a cada servi\u00e7o\/microservi\u00e7o no conjunto do SI.
\n\u00c9 importante destacar a obrigatoriedade de dados sobre o impacto do SI nos neg\u00f3cios principais da empresa, em forma de custo de paralisa\u00e7\u00e3o do SI (rublos por hora).<\/p>\n

Modelo de amea\u00e7as<\/b><\/p>\n

Deve haver um modelo formal de amea\u00e7as, que se pretende proteger os dados\/servi\u00e7os. Este modelo de amea\u00e7as inclui n\u00e3o apenas aspectos de confidencialidade, mas tamb\u00e9m de integridade e disponibilidade. Ou seja, por exemplo:
\n \u2014 Falha de um servidor f\u00edsico;
\n \u2014 Falha de um comutador top-of-the-rack;
\n \u2014 Quebra do canal de comunica\u00e7\u00e3o \u00f3ptica entre os datacenters;
\n \u2014 Falha total do sistema de armazenamento de dados em opera\u00e7\u00e3o.
\nEm alguns casos, os modelos de amea\u00e7as s\u00e3o elaborados n\u00e3o apenas para componentes de infraestrutura, mas tamb\u00e9m para sistemas espec\u00edficos ou seus componentes, como a falha do SGBD com a destrui\u00e7\u00e3o l\u00f3gica da estrutura dos dados.
\nTodas as decis\u00f5es no \u00e2mbito do projeto para prote\u00e7\u00e3o contra amea\u00e7as n\u00e3o descritas s\u00e3o excessivas.<\/p>\n

Requisitos dos reguladores<\/b><\/p>\n

Se os dados processados est\u00e3o sujeitos a regras especiais estabelecidas pelos reguladores, \u00e9 obrigat\u00f3ria a informa\u00e7\u00e3o sobre conjuntos de dados e regras de processamento\/armazenamento.<\/p>\n

Indicadores-alvo de RPO\/RTO<\/b><\/p>\n

O projeto de qualquer tipo de prote\u00e7\u00e3o requer a exist\u00eancia de indicadores de perda de dados alvo e tempo de recupera\u00e7\u00e3o do servi\u00e7o para cada uma das amea\u00e7as descritas.
\nIdealmente, RPO e RTO devem ter custos associados \u00e0 perda de dados e paralisa\u00e7\u00e3o por unidade de tempo.<\/p>\n

\"Design
\n
\nDivis\u00e3o em pools de recursos<\/b><\/p>\n

Ap\u00f3s a coleta de todas as informa\u00e7\u00f5es iniciais, o primeiro passo \u00e9 agrupar conjuntos de dados e SI em pools, com base em modelos de amea\u00e7as e requisitos dos reguladores. Define-se o tipo de separa\u00e7\u00e3o entre diferentes pools \u2013 programaticamente ao n\u00edvel do software do sistema ou fisicamente.
\nExemplos:
\n \u2014 O contorno que processa dados pessoais \u00e9 completamente fisicamente separado dos outros sistemas;
\n \u2014 Backups s\u00e3o armazenados em um sistema de armazenamento separado.<\/p>\n

Nesse caso, os pools podem ter independ\u00eancia parcial; por exemplo, definem-se dois pools de recursos computacionais (poder de processamento + mem\u00f3ria operacional), que utilizam um \u00fanico pool de armazenamento de dados e um \u00fanico pool de recursos de transmiss\u00e3o de dados.<\/p>\n

Poder de processamento<\/b><\/p>\n

\"Design
\n
\nAs necessidades abstratas de poder de processamento em um data center virtualizado s\u00e3o medidas pela quantidade de processadores virtuais (vCPU) e pela taxa de consolida\u00e7\u00e3o em processadores f\u00edsicos (pCPU). Neste caso espec\u00edfico, 1 pCPU = 1 n\u00facleo f\u00edsico do processador (sem considerar o Hyper-Threading). O n\u00famero de vCPUs \u00e9 somado a todos os pools de recursos designados (cada um dos quais pode ter sua pr\u00f3pria taxa de consolida\u00e7\u00e3o).
\nA taxa de consolida\u00e7\u00e3o para sistemas sobrecarregados \u00e9 obtida empiricamente com base na infraestrutura existente ou durante instala\u00e7\u00f5es piloto e testes de carga. Para sistemas sem carga, s\u00e3o aplicadas as 'melhores pr\u00e1ticas'. Especificamente, a VMware considera uma taxa m\u00e9dia de 8:1.<\/p>\n

Mem\u00f3ria RAM<\/b><\/p>\n

A necessidade total de mem\u00f3ria RAM \u00e9 obtida atrav\u00e9s de uma simples soma. O uso de superaprova\u00e7\u00e3o de mem\u00f3ria RAM n\u00e3o \u00e9 recomendado.<\/p>\n

Recursos de armazenamento<\/b><\/p>\n

Os requisitos de armazenamento s\u00e3o obtidos pela simples soma de todos os pools em termos de volume e desempenho.
\nOs requisitos de desempenho s\u00e3o expressos em IOPS, em conjunto com a taxa m\u00e9dia de leitura\/escrita e, se necess\u00e1rio, com a lat\u00eancia de resposta m\u00e1xima.
\nDeve-se especificar separadamente os requisitos de garantia de qualidade de servi\u00e7o (QoS) para pools ou sistemas espec\u00edficos.<\/p>\n

Recursos de rede de dados<\/b><\/p>\n

Os requisitos de rede de dados s\u00e3o obtidos pela simples soma de todos os pools de largura de banda.
\nDeve-se especificar separadamente os requisitos de garantia de qualidade de servi\u00e7o (QoS) e lat\u00eancias (RTT) para pools ou sistemas espec\u00edficos.
\nDentro dos requisitos de recursos de rede de dados, tamb\u00e9m s\u00e3o especificados os requisitos de isolamento e\/ou criptografia do tr\u00e1fego de rede e os mecanismos preferenciais (802.1q, IPSec, etc.).<\/p>\n

Escolha da arquitetura<\/b><\/p>\n

Este guia n\u00e3o considera outra escolha al\u00e9m da arquitetura x86 e da virtualiza\u00e7\u00e3o 100% dos servidores. Portanto, a escolha da arquitetura da subsistema computacional se resume \u00e0 escolha da plataforma de virtualiza\u00e7\u00e3o de servidores, do formato dos servidores e dos requisitos gerais de configura\u00e7\u00e3o dos servidores.<\/p>\n

O ponto chave na escolha \u00e9 a clareza em usar a abordagem cl\u00e1ssica de separa\u00e7\u00e3o das fun\u00e7\u00f5es de processamento, armazenamento e transmiss\u00e3o de dados ou uma abordagem convergente.<\/p>\n

Arquitetura cl\u00e1ssica<\/i> implica o uso de subsistemas externos inteligentes de armazenamento e transmiss\u00e3o de dados, enquanto os servidores contribuem para o pool geral de recursos f\u00edsicos apenas com poder de processamento e mem\u00f3ria RAM. No limite, os servidores tornam-se completamente an\u00f4nimos, n\u00e3o possuindo n\u00e3o apenas seus pr\u00f3prios discos, mas at\u00e9 mesmo um identificador de sistema. Neste caso, utiliza-se o carregamento do SO ou hipervisor a partir de dispositivos flash embutidos ou de um sistema de armazenamento externo (boot from SAN).
\nDentro da arquitetura cl\u00e1ssica, a escolha entre l\u00e2minas (blade) e servidores em rack \u00e9 feita principalmente pelos seguintes princ\u00edpios:
\n \u2014 Efici\u00eancia econ\u00f4mica (em m\u00e9dia, servidores em rack s\u00e3o mais baratos);
\n \u2014 Densidade computacional (as l\u00e2minas t\u00eam uma densidade maior);
\n \u2014 Consumo de energia e dissipa\u00e7\u00e3o de calor (as l\u00e2minas t\u00eam um consumo unit\u00e1rio maior);
\n \u2014 Escalabilidade e gerenciabilidade (as l\u00e2minas, em geral, requerem menos esfor\u00e7o em grandes instala\u00e7\u00f5es);
\n \u2014 Uso de placas de expans\u00e3o (para l\u00e2minas, a escolha \u00e9 muito limitada).
\nArquitetura convergente<\/i> (tamb\u00e9m conhecida como hiperconvergente<\/i>) pressup\u00f5e a combina\u00e7\u00e3o de fun\u00e7\u00f5es de processamento e armazenamento de dados, o que leva ao uso de discos locais nos servidores e, como consequ\u00eancia, \u00e0 rejei\u00e7\u00e3o do fator de forma cl\u00e1ssico das l\u00e2minas. Sistemas convergentes utilizam servidores em rack ou sistemas de cluster que combinam em um \u00fanico gabinete v\u00e1rios servidores-l\u00e2minas e discos locais.<\/p>\n

CPU \/ Mem\u00f3ria <\/b><\/p>\n

Para calcular corretamente a configura\u00e7\u00e3o, \u00e9 necess\u00e1rio entender o tipo de carga para o ambiente ou cada um dos clusters independentes.
\nLimitado por CPU<\/i> \u2013 um ambiente limitado pelo poder de desempenho da CPU. Adicionar mem\u00f3ria RAM n\u00e3o altera nada em termos de desempenho (n\u00famero de VMs por servidor).
\nLimitado por Mem\u00f3ria<\/i> \u2013 um ambiente limitado pela mem\u00f3ria RAM. Uma maior quantidade de mem\u00f3ria RAM no servidor permite a execu\u00e7\u00e3o de um n\u00famero maior de VMs no servidor.
\nGB \/ MHz (GB \/ pCPU) \u2013 a m\u00e9dia da rela\u00e7\u00e3o de consumo de mem\u00f3ria RAM e poder de processamento para essa carga espec\u00edfica. Pode ser usado para calcular o volume necess\u00e1rio de mem\u00f3ria para um desempenho espec\u00edfico e vice-versa. <\/p>\n

C\u00e1lculo da configura\u00e7\u00e3o do servidor<\/b><\/p>\n

\"Design
\n
\nPrimeiro, \u00e9 necess\u00e1rio identificar todos os tipos de carga e decidir sobre a combina\u00e7\u00e3o ou divis\u00e3o de diferentes pools computacionais entre v\u00e1rios clusters.
\nEm seguida, para cada um dos clusters identificados, determina-se a rela\u00e7\u00e3o GB \/ MHz com uma carga conhecida previamente. Se a carga n\u00e3o for conhecida, mas houver uma compreens\u00e3o aproximada do n\u00edvel de utiliza\u00e7\u00e3o da capacidade da CPU, podem-se usar coeficientes padr\u00e3o vCPU:pCPU para converter as necessidades dos pools em f\u00edsicos. <\/p>\n

Para cada cluster, a soma das necessidades dos pools vCPU \u00e9 dividida pelo coeficiente:
\nvCPUtotal \/ vCPU:pCPU = pCPUtotal \u2013 n\u00famero necess\u00e1rio de n\u00facleos f\u00edsicos
\npCPUtotal \/ 1.25 = pCPUht \u2013 n\u00famero de n\u00facleos com corre\u00e7\u00e3o de Hyper-Threading
\nSuponha que seja necess\u00e1rio calcular um cluster com 190 n\u00facleos \/ 3.5TB de RAM. Para isso, aceitamos uma carga alvo de 50% da capacidade da CPU e 75% da mem\u00f3ria.<\/p>\n

pCPU<\/b>
\n190
\nUtiliza\u00e7\u00e3o da CPU<\/b>
\n50%<\/p>\n

Mem<\/b>
\n3500
\nUtiliza\u00e7\u00e3o da Mem\u00f3ria<\/b>
\n75%<\/p>\n

Soquete<\/b>
\nN\u00facleo<\/b>
\nSrv \/ CPU<\/b>
\nSrv Mem<\/b>
\nSrv \/ Mem<\/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

Neste caso, sempre utilizamos o arredondamento para cima para o inteiro mais pr\u00f3ximo (=ROUNDUP(A1;0)).
\nDa tabela, fica claro que configura\u00e7\u00f5es de servidores equilibradas para as metas alvo s\u00e3o v\u00e1rias:
\n \u2014 26 servidores 2*6c \/ 192 GB
\n \u2014 19 servidores 2*10c \/ 256 GB
\n \u2014 10 servidores 2*18c \/ 512 GB <\/p>\n

A escolha entre essas configura\u00e7\u00f5es deve ser feita com base em fatores adicionais, como o pacote t\u00e9rmico e o resfriamento dispon\u00edvel, servidores j\u00e1 utilizados ou custos.<\/p>\n

Caracter\u00edsticas da escolha da configura\u00e7\u00e3o do servidor<\/b><\/p>\n

M\u00e1quinas Virtuais Amplas. Quando for necess\u00e1rio hospedar VMs amplas (compar\u00e1veis a 1 n\u00f3 NUMA ou mais), \u00e9 recomend\u00e1vel escolher um servidor com uma configura\u00e7\u00e3o que permita a essas VMs permanecer dentro do n\u00f3 NUMA. Com um grande n\u00famero de VMs amplas, h\u00e1 um risco de fragmenta\u00e7\u00e3o dos recursos do cluster, e, neste caso, devem ser escolhidos servidores que permitam acomodar as VMs amplas o mais densamente poss\u00edvel.<\/p>\n

Tamanho do dom\u00ednio de falha unit\u00e1ria.<\/b> <\/p>\n

A escolha do tamanho do servidor tamb\u00e9m \u00e9 feita com base no princ\u00edpio de minimizar o dom\u00ednio de falha unit\u00e1ria. Por exemplo, ao escolher entre:
\n \u2014 3 x 4*10c \/ 512 GB
\n \u2014 6 x 2*10c \/ 256 GB
\nCom outras condi\u00e7\u00f5es iguais, deve-se escolher a segunda op\u00e7\u00e3o, pois ao falhar um servidor (ou durante a manuten\u00e7\u00e3o), n\u00e3o se perde 33% dos recursos do cluster, mas 17%. Da mesma forma, o n\u00famero de VMs e sistemas impactados pela falha \u00e9 reduzido pela metade.<\/p>\n

C\u00e1lculo de armazenamento cl\u00e1ssico por desempenho<\/b><\/p>\n

\"Design
\n
\nO armazenamento cl\u00e1ssico \u00e9 sempre calculado com base no pior cen\u00e1rio, excluindo o impacto do cache em disco e a otimiza\u00e7\u00e3o das opera\u00e7\u00f5es.
\nComo m\u00e9tricas b\u00e1sicas de desempenho, consideramos o desempenho mec\u00e2nico do disco (IOPSdisk):
\n \u2014 7.2k \u2013 75 IOPS
\n \u2014 10k \u2013 125 IOPS
\n \u2014 15k \u2013 175 IOPS<\/p>\n

Em seguida, a quantidade de discos no pool \u00e9 calculada pela seguinte f\u00f3rmula: = TotalIOPS * ( RW + (1 \u2013RW) * RAIDPen) \/ IOPSdisk<\/i>. Onde:
\n \u2014 TotalIOPS<\/i> \u2013 a performance total requerida em IOPS do pool de discos
\n \u2014 RW<\/i> \u2013 a porcentagem de opera\u00e7\u00f5es de leitura
\n \u2014 RAIDpen<\/i> \u2013 penalidade RAID para o n\u00edvel RAID escolhido<\/p>\n

Saiba mais sobre dispositivos RAID e RAID Penalty aqui \u2014 Desempenho do armazenamento. Parte um.<\/a><\/noindex> e Desempenho do armazenamento. Parte dois.<\/a><\/noindex> e Desempenho do armazenamento. Parte tr\u00eas.<\/a><\/noindex><\/p>\n

Com base no n\u00famero de discos obtido, s\u00e3o calculadas as op\u00e7\u00f5es poss\u00edveis que atendem aos requisitos de capacidade de armazenamento, incluindo op\u00e7\u00f5es com armazenamento em m\u00faltiplos n\u00edveis.
\nO c\u00e1lculo de sistemas usando SSD como n\u00edvel de armazenamento \u00e9 tratado separadamente.
\nCaracter\u00edsticas do c\u00e1lculo de sistemas com Flash Cache
\n<\/b><\/p>\n

Flash Cache<\/i> \u2013 um termo gen\u00e9rico para todas as tecnologias propriet\u00e1rias que utilizam mem\u00f3ria flash como cache de segundo n\u00edvel. Ao usar o cache flash, o armazenamento \u00e9 geralmente calculado para atender \u00e0 carga estabelecida a partir de discos magn\u00e9ticos, enquanto a carga de pico \u00e9 atendida pelo cache.
\n\u00c9 necess\u00e1rio entender o perfil da carga e o grau de localiza\u00e7\u00e3o dos acessos aos blocos dos volumes de armazenamento. O Flash Cache \u00e9 uma tecnologia para cargas com alta localiza\u00e7\u00e3o de solicita\u00e7\u00f5es e \u00e9 praticamente inaplic\u00e1vel a volumes com carga uniforme (como em sistemas de an\u00e1lise). <\/p>\n

C\u00e1lculo de sistemas h\u00edbridos low-end \/ mid-range<\/b><\/p>\n

Os sistemas h\u00edbridos de baixo e m\u00e9dio custo usam armazenamento em m\u00faltiplos n\u00edveis com movimenta\u00e7\u00e3o de dados entre n\u00edveis em agenda. Neste caso, o tamanho do bloco de armazenamento em m\u00faltiplos n\u00edveis nos melhores modelos \u00e9 de 256 MB. Essas caracter\u00edsticas n\u00e3o permitem considerar a tecnologia de armazenamento em m\u00faltiplos n\u00edveis como uma tecnologia de aumento de desempenho, como muitas vezes \u00e9 erroneamente considerada. O armazenamento em m\u00faltiplos n\u00edveis em sistemas de baixo e m\u00e9dio custo \u00e9 uma tecnologia de otimiza\u00e7\u00e3o de custo de armazenamento para sistemas com carga desigual.<\/p>\n

Para armazenamento em m\u00faltiplos n\u00edveis, a performance do n\u00edvel superior \u00e9 priorizada, enquanto o n\u00edvel inferior \u00e9 considerado apenas como um complemento \u00e0 capacidade de armazenamento. Para um sistema h\u00edbrido de m\u00faltiplos n\u00edveis, o uso de tecnologia de cache flash \u00e9 essencial para compensar a queda de desempenho de dados de baixo n\u00edvel que ficam temporariamente ativos.<\/p>\n

Uso de SSD em um pool de discos de m\u00faltiplos n\u00edveis<\/b><\/p>\n

\"Design
\n
\nO uso de SSD em um pool de discos de m\u00faltiplos n\u00edveis varia conforme as particularidades da implementa\u00e7\u00e3o dos algoritmos de cache flash deste fornecedor.
\nA pr\u00e1tica comum de pol\u00edtica de armazenamento para um pool de discos com n\u00edvel SSD \u00e9 SSD first.
\nCache Flash Somente para Leitura.<\/i> Para um cache flash de somente leitura, o n\u00edvel de armazenamento em SSD \u00e9 ativado quando h\u00e1 uma significativa localiza\u00e7\u00e3o das opera\u00e7\u00f5es de escrita, independentemente do cache.
\nCache Flash Leitura \/ Escrita.<\/i> No caso de um cache flash para escrita, primeiro define-se o tamanho m\u00e1ximo do cache, e o n\u00edvel de armazenamento em SSD surge apenas quando n\u00e3o h\u00e1 espa\u00e7o suficiente no cache para atender a toda a carga localizada.
\nO c\u00e1lculo do desempenho de SSD e cache \u00e9 sempre realizado com base nas recomenda\u00e7\u00f5es do fabricante, mas sempre levando em considera\u00e7\u00e3o o pior cen\u00e1rio.
\n
Fonte: 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\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\udd47Design de Data Center Virtualizado | ProHoster","description":"Introdu\u00e7\u00e3o ao Sistema de Informa\u00e7\u00e3o sobre o ponto.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/35800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=35800"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/35800\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/26806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=35800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=35800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=35800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}