{"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\/es\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","title":{"rendered":"Dise\u00f1o de un centro de datos virtualizado","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Dise\u00f1o
\n
\nIntroducci\u00f3n<\/b><\/p>\n

El sistema de informaci\u00f3n desde el punto de vista del usuario se define bien en la norma \u0413\u041e\u0421\u0422 \u0420\u0412 51987 como \u00abun sistema automatizado, cuyo resultado del funcionamiento es la presentaci\u00f3n de informaci\u00f3n de salida para su uso posterior\u00bb. Si consideramos la estructura interna, cualquier SI es en esencia un sistema de algoritmos interrelacionados implementados en c\u00f3digo. En un sentido amplio, el teorema de Turing-Church establece que un algoritmo (y, por lo tanto, el SI) transforma un conjunto de datos de entrada en un conjunto de datos de salida.
\nSe podr\u00eda incluso decir que el sentido de existencia de un sistema de informaci\u00f3n radica en la transformaci\u00f3n de los datos de entrada. En consecuencia, el valor del SI y de todo el conjunto de SIs se determina a trav\u00e9s del valor de los datos de entrada y salida.
\nA partir de esto, el dise\u00f1o debe comenzar y basarse en los datos, adaptando la arquitectura y los m\u00e9todos a la estructura y la importancia de los datos.<\/p>\n

Datos almacenados<\/b>
\nUna etapa clave en la preparaci\u00f3n para el dise\u00f1o es obtener las caracter\u00edsticas de todos los conjuntos de datos que se planifican para su procesamiento y almacenamiento. Estas caracter\u00edsticas incluyen:
\n \u2014 Volumen de datos;
\n \u2014 Informaci\u00f3n sobre el ciclo de vida de los datos (crecimiento de nuevos datos, tiempo de vida, procesamiento de datos obsoletos);
\n \u2014 Clasificaci\u00f3n de los datos desde la perspectiva de su influencia en el negocio principal de la empresa (la tr\u00edada de confidencialidad, integridad, disponibilidad) junto con indicadores financieros (por ejemplo, el costo de la p\u00e9rdida de datos en la \u00faltima hora);
\n \u2014 Geograf\u00eda del procesamiento de datos (ubicaci\u00f3n f\u00edsica de los sistemas de procesamiento);
\n \u2014 Requisitos de los reguladores para cada clase de datos (por ejemplo, la Ley Federal 152, PCI DSS).<\/p>\n

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

Sistemas de informaci\u00f3n<\/b><\/p>\n

Los datos no solo se almacenan, sino que tambi\u00e9n son procesados (transformados) por los sistemas de informaci\u00f3n. El siguiente paso despu\u00e9s de obtener las caracter\u00edsticas de los datos es realizar un inventario lo m\u00e1s completo posible de los sistemas de informaci\u00f3n, sus caracter\u00edsticas arquitect\u00f3nicas, interdependencias y requisitos de infraestructura en unidades condicionales para cuatro tipos de recursos:
\n \u2014 Potencia de c\u00e1lculo del procesador;
\n \u2014 Volumen de memoria RAM;
\n \u2014 Requisitos de volumen y rendimiento del sistema de almacenamiento de datos;
\n \u2014 Requisitos para la red de transmisi\u00f3n de datos (canales externos, canales entre componentes del SI).
\nLos requisitos deben establecerse para cada servicio\/microservicio en el sistema de informaci\u00f3n.
\nEs importante se\u00f1alar la necesidad de contar con datos sobre el impacto del sistema de informaci\u00f3n en el negocio principal de la empresa, en forma de costo de inactividad del sistema de informaci\u00f3n (rublos por hora).<\/p>\n

Modelo de amenazas<\/b><\/p>\n

Es obligatoria la existencia de un modelo formal de amenazas que proteja los datos\/servicios. Este modelo incluye no solo aspectos de confidencialidad, sino tambi\u00e9n de integridad y disponibilidad. Por ejemplo:
\n \u2014 Fallo de un servidor f\u00edsico;
\n \u2014 Ca\u00edda de un conmutador top-of-the-rack;
\n \u2014 Corte de un canal de comunicaci\u00f3n \u00f3ptica entre los centros de datos;
\n \u2014 Fallo total de un sistema de almacenamiento temporal.
\nEn algunos casos, los modelos de amenazas se redactan no solo para componentes de infraestructura, sino tambi\u00e9n para sistemas de informaci\u00f3n espec\u00edficos o sus componentes, como la falla de un sistema de gesti\u00f3n de bases de datos con una destrucci\u00f3n l\u00f3gica de la estructura de datos.
\nCualquier decisi\u00f3n en el proyecto para protegerse contra amenazas no descritas es superflua.<\/p>\n

Requisitos de los reguladores<\/b><\/p>\n

Si los datos procesados est\u00e1n sujetos a reglas especiales establecidas por los reguladores, se necesita obligatoriamente informaci\u00f3n sobre conjuntos de datos y reglas de procesamiento\/almacenamiento.<\/p>\n

Indicadores objetivos RPO\/RTO<\/b><\/p>\n

El dise\u00f1o de cualquier tipo de protecci\u00f3n requiere la existencia de indicadores de p\u00e9rdida de datos objetivo y del tiempo de recuperaci\u00f3n objetivo del servicio para cada una de las amenazas descritas.
\nIdealmente, RPO y RTO deben tener costos asociados de p\u00e9rdida de datos y de inactividad por unidad de tiempo.<\/p>\n

\"Dise\u00f1o
\n
\nDivisi\u00f3n en grupos de recursos<\/b><\/p>\n

Despu\u00e9s de recoger toda la informaci\u00f3n inicial, el primer paso es agrupar conjuntos de datos y sistemas de informaci\u00f3n en grupos, bas\u00e1ndose en modelos de amenazas y requisitos regulatorios. Se determina la forma de segmentaci\u00f3n de los diferentes grupos: program\u00e1ticamente a nivel de software del sistema o f\u00edsicamente.
\nEjemplos:
\n \u2014 El contorno que procesa datos personales est\u00e1 completamente f\u00edsicamente separado de los dem\u00e1s sistemas;
\n \u2014 Las copias de seguridad se almacenan en un sistema de almacenamiento separado.<\/p>\n

Estos grupos pueden tener independencia parcial, por ejemplo, se definen dos grupos de recursos computacionales (potencia de CPU + memoria RAM) que utilizan un \u00fanico grupo de almacenamiento de datos y un \u00fanico grupo de recursos de transmisi\u00f3n de datos.<\/p>\n

Potencia de CPU<\/b><\/p>\n

\"Dise\u00f1o
\n
\nLas necesidades abstractas de potencia de procesamiento de un centro de datos virtualizado se miden en la cantidad de procesadores virtuales (vCPU) y el coeficiente de consolidaci\u00f3n en procesadores f\u00edsicos (pCPU). En este caso espec\u00edfico, 1 pCPU = 1 n\u00facleo f\u00edsico del procesador (sin tener en cuenta el Hyper-Threading). La cantidad de vCPU se suma de todos los grupos de recursos definidos (cada uno de los cuales puede tener su propio coeficiente de consolidaci\u00f3n).
\nEl coeficiente de consolidaci\u00f3n para sistemas cargados se obtiene emp\u00edricamente, bas\u00e1ndose en la infraestructura existente, o mediante la instalaci\u00f3n piloto y pruebas de carga. Para sistemas no cargados, se aplican buenas pr\u00e1cticas. En particular, VMware menciona un coeficiente medio de 8:1.<\/p>\n

Memoria RAM<\/b><\/p>\n

La necesidad total de memoria RAM se obtiene mediante una simple suma. No se recomienda el uso de sobreasignaci\u00f3n de memoria RAM.<\/p>\n

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

Los requisitos de recursos de almacenamiento se obtienen sumando todos los grupos en t\u00e9rminos de volumen y rendimiento.
\nLos requisitos de rendimiento se expresan en IOPS en combinaci\u00f3n con la relaci\u00f3n media de lectura\/escritura y, si es necesario, la latencia m\u00e1xima de respuesta.
\nLos requisitos de calidad de servicio (QoS) deben especificarse por separado para grupos o sistemas espec\u00edficos.<\/p>\n

Recursos de red de datos<\/b><\/p>\n

Los requisitos de red de datos se obtienen sumando todos los grupos de ancho de banda.
\nLos requisitos de calidad de servicio (QoS) y las latencias (RTT) deben especificarse por separado para grupos o sistemas espec\u00edficos.
\nEn los requisitos de recursos de red de datos tambi\u00e9n se indican las necesidades de aislamiento y\/o cifrado del tr\u00e1fico de red y los mecanismos preferidos (802.1q, IPSec, etc.).<\/p>\n

Selecci\u00f3n de arquitectura<\/b><\/p>\n

En esta gu\u00eda no se considera ninguna opci\u00f3n m\u00e1s que la arquitectura x86 y la virtualizaci\u00f3n del 100% de los servidores. Por lo tanto, la selecci\u00f3n de la arquitectura del subsistema computacional se limita a elegir la plataforma de virtualizaci\u00f3n del servidor, el factor de forma de los servidores y los requisitos generales de configuraci\u00f3n de los servidores.<\/p>\n

Un punto clave en la selecci\u00f3n es la claridad en el uso del enfoque cl\u00e1sico con separaci\u00f3n de funciones de procesamiento, almacenamiento y transmisi\u00f3n de datos o el enfoque convergente.<\/p>\n

Arquitectura cl\u00e1sica<\/i> implica el uso de subsistemas externos inteligentes para el almacenamiento y la transmisi\u00f3n de datos, mientras que los servidores contribuyen al conjunto com\u00fan de recursos f\u00edsicos solo con potencia de CPU y memoria RAM. En el caso extremo, los servidores se vuelven completamente an\u00f3nimos, sin discos propios ni siquiera un identificador del sistema. En este caso, se utiliza la carga del sistema operativo o del hipervisor desde dispositivos flash integrados o desde un sistema de almacenamiento externo (boot from SAN).
\nEn el marco de la arquitectura cl\u00e1sica, la elecci\u00f3n entre blades y servidores en rack se basa principalmente en los siguientes principios:
\n \u2014 Eficiencia econ\u00f3mica (en promedio, los servidores en rack son m\u00e1s baratos);
\n \u2014 Densidad computacional (los blades tienen mayor densidad);
\n \u2014 Consumo de energ\u00eda y generaci\u00f3n de calor (los blades tienen mayor consumo espec\u00edfico por unidad);
\n \u2014 Escalabilidad y gestionabilidad (los blades en general requieren menos esfuerzo en instalaciones grandes);
\n \u2014 Uso de tarjetas de expansi\u00f3n (para los blades, la elecci\u00f3n es muy limitada).
\nArquitectura convergente<\/i> (tambi\u00e9n conocida como hiperconvergente<\/i>) implica la integraci\u00f3n de funciones de procesamiento y almacenamiento de datos, lo que lleva al uso de discos locales en los servidores y, como consecuencia, al abandono del factor de forma de los blades cl\u00e1sicos. Para los sistemas convergentes se utilizan servidores en rack o sistemas de cl\u00faster que combinan en un solo chasis varios servidores blades y discos locales.<\/p>\n

CPU \/ Memoria <\/b><\/p>\n

Para calcular correctamente la configuraci\u00f3n, es necesario entender el tipo de carga para el entorno o cada uno de los cl\u00fasteres independientes.
\nCPU bound<\/i> \u2013 entorno limitado por la capacidad de procesamiento de la CPU. Agregar memoria RAM no cambiar\u00e1 nada en t\u00e9rminos de rendimiento (n\u00famero de VM en el servidor).
\nMemory bound<\/i> \u2013 entorno limitado por la memoria RAM. Una mayor cantidad de memoria RAM en el servidor permite iniciar un mayor n\u00famero de VM en el servidor.
\nGB \/ MHz (GB \/ pCPU) \u2013 la relaci\u00f3n promedio de consumo de memoria RAM y potencia de CPU para esta carga espec\u00edfica. Puede utilizarse para calcular el volumen necesario de memoria dado un rendimiento especificado y viceversa. <\/p>\n

C\u00e1lculo de la configuraci\u00f3n del servidor<\/b><\/p>\n

\"Dise\u00f1o
\n
\nPara empezar, es necesario definir todos los tipos de carga y tomar una decisi\u00f3n sobre la combinaci\u00f3n o separaci\u00f3n de diferentes grupos computacionales en distintos cl\u00fasteres.
\nA continuaci\u00f3n, para cada uno de los cl\u00fasteres definidos se determina la relaci\u00f3n GB \/ MHz con una carga conocida de antemano. Si la carga no se conoce de antemano, pero hay una comprensi\u00f3n aproximada del nivel de utilizaci\u00f3n de la potencia del procesador, se pueden utilizar coeficientes est\u00e1ndar vCPU:pCPU para traducir los requisitos de los grupos en f\u00edsico. <\/p>\n

Para cada cl\u00faster, sumamos los requisitos de los grupos vCPU y los dividimos por el coeficiente:
\nvCPUsum \/ vCPU:pCPU = pCPUsum \u2013 cantidad requerida de n\u00facleos f\u00edsicos
\npCPUsum \/ 1.25 = pCPUht \u2013 cantidad de n\u00facleos con ajuste por Hyper-Threading
\nSupongamos que es necesario calcular un cl\u00faster de 190 n\u00facleos \/ 3.5 TB de RAM. Tomamos como objetivo una carga del 50% de la potencia del procesador y del 75% de la memoria RAM.<\/p>\n

pCPU<\/b>
\n190
\nutilizaci\u00f3n de CPU<\/b>
\n50%<\/p>\n

Mem<\/b>
\n3500
\nutilizaci\u00f3n de Mem<\/b>
\n75%<\/p>\n

Socket<\/b>
\nCore<\/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

En este caso, siempre usamos el redondeo hacia el entero m\u00e1s pr\u00f3ximo hacia arriba (=REDONDEAR(A1,0)).
\nDe la tabla se hace evidente que las configuraciones de servidores equilibradas seg\u00fan los indicadores objetivo son varias:
\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

La elecci\u00f3n entre estas configuraciones debe hacerse considerando factores adicionales, como el paquete t\u00e9rmico y la refrigeraci\u00f3n disponible, los servidores ya usados o el costo.<\/p>\n

Caracter\u00edsticas de la elecci\u00f3n de la configuraci\u00f3n del servidor<\/b><\/p>\n

M\u00e1quinas virtuales amplias. Si es necesario alojar m\u00e1quinas virtuales amplias (comparables a 1 nodo NUMA o m\u00e1s), se recomienda, en la medida de lo posible, elegir un servidor cuya configuraci\u00f3n permita que tales VM permanezcan dentro del nodo NUMA. Con un gran n\u00famero de m\u00e1quinas virtuales amplias, existe el riesgo de fragmentaci\u00f3n de los recursos del cl\u00faster, y en este caso se eligen servidores que permiten alojar m\u00e1quinas virtuales amplias de la manera m\u00e1s compacta posible.<\/p>\n

Tama\u00f1o del dominio de falla \u00fanica.<\/b> <\/p>\n

La elecci\u00f3n del tama\u00f1o del servidor tambi\u00e9n se basa en el principio de minimizar el dominio de falla \u00fanica. Por ejemplo, al elegir entre:
\n \u2014 3 x 4*10c \/ 512 GB
\n \u2014 6 x 2*10c \/ 256 GB
\nCon igualdad de condiciones, se debe elegir la segunda opci\u00f3n, ya que al fallar un servidor (o durante su mantenimiento) no se pierde el 33% de los recursos del cl\u00faster, sino el 17%. De igual manera, se reduce a la mitad el n\u00famero de VM e IS afectadas por la falla.<\/p>\n

C\u00e1lculo de almacenamiento de clase cl\u00e1sica seg\u00fan el rendimiento<\/b><\/p>\n

\"Dise\u00f1o
\n
\nEl almacenamiento de clase cl\u00e1sica siempre se calcula seg\u00fan el peor escenario (worst case scenario), excluyendo la influencia de la cach\u00e9 de memoria y la optimizaci\u00f3n de operaciones.
\nComo indicadores b\u00e1sicos de rendimiento, tomamos el rendimiento mec\u00e1nico del disco (IOPSdisk):
\n \u2014 7.2k \u2013 75 IOPS
\n \u2014 10k \u2013 125 IOPS
\n \u2014 15k \u2013 175 IOPS<\/p>\n

A continuaci\u00f3n, el n\u00famero de discos en el pool de discos se calcula mediante la siguiente f\u00f3rmula: = TotalIOPS * ( RW + (1 \u2013RW) * RAIDPen) \/ IOPSdisk<\/i>. Donde:
\n \u2014 TotalIOPS<\/i> \u2013 rendimiento total requerido en IOPS del pool de discos
\n \u2014 RW<\/i> \u2013 porcentaje de operaciones de lectura
\n \u2014 RAIDpen<\/i> \u2013 penalizaci\u00f3n RAID para el nivel RAID seleccionado<\/p>\n

M\u00e1s informaci\u00f3n sobre el dispositivo RAID y la Penalizaci\u00f3n RAID se puede encontrar aqu\u00ed \u2014 Rendimiento del almacenamiento. Parte primero.<\/a><\/noindex> y Rendimiento del almacenamiento. Parte segunda.<\/a><\/noindex> y Rendimiento del almacenamiento. Parte tercera<\/a><\/noindex><\/p>\n

A partir del n\u00famero de discos obtenido, se calculan las opciones posibles que satisfacen los requisitos de capacidad de almacenamiento, incluyendo opciones con almacenamiento jer\u00e1rquico.
\nEl c\u00e1lculo de sistemas utilizando SSD como nivel de almacenamiento se considera por separado.
\nCaracter\u00edsticas del c\u00e1lculo de sistemas con Flash Cache
\n<\/b><\/p>\n

Flash Cache<\/i> \u2013 nombre gen\u00e9rico para todas las tecnolog\u00edas propietarias que utilizan memoria flash como cach\u00e9 de segundo nivel. Al utilizar cach\u00e9 flash, el almacenamiento de clase generalmente se calcula para proporcionar la carga establecida desde discos magn\u00e9ticos, mientras que el pico es manejado por la cach\u00e9.
\nEs necesario comprender el perfil de carga y el grado de localizaci\u00f3n de los accesos a los bloques de los vol\u00famenes de almacenamiento. Flash Cache es una tecnolog\u00eda para cargas con alta localizaci\u00f3n de solicitudes y pr\u00e1cticamente no es aplicable para vol\u00famenes cargados uniformemente (como sucede en sistemas anal\u00edticos). <\/p>\n

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

Los sistemas h\u00edbridos de gama baja y media utilizan almacenamiento jer\u00e1rquico con movimiento de datos entre niveles seg\u00fan un horario. En este caso, el tama\u00f1o del bloque de almacenamiento jer\u00e1rquico en los mejores modelos es de 256 MB. Estas caracter\u00edsticas no permiten considerar la tecnolog\u00eda de almacenamiento jer\u00e1rquico como una tecnolog\u00eda de aumento de rendimiento, como err\u00f3neamente piensan muchos. El almacenamiento jer\u00e1rquico en sistemas de gama baja y media es una tecnolog\u00eda de optimizaci\u00f3n de costos de almacenamiento para sistemas con una notable desigualdad de carga.<\/p>\n

Para el almacenamiento en m\u00faltiples niveles, se calcula principalmente el rendimiento del nivel superior, mientras que el nivel inferior se considera solo para proporcionar la capacidad de almacenamiento faltante. Para un sistema h\u00edbrido de m\u00faltiples niveles, es imprescindible el uso de tecnolog\u00eda de cach\u00e9 de flash para el grupo de m\u00faltiples niveles, con el fin de compensar la ca\u00edda de rendimiento para los datos que se calientan repentinamente desde el nivel inferior.<\/p>\n

Uso de SSD en un grupo de discos de m\u00faltiples niveles<\/b><\/p>\n

\"Dise\u00f1o
\n
\nEl uso de SSD en un grupo de discos de m\u00faltiples niveles tiene variaciones, dependiendo de las caracter\u00edsticas de implementaci\u00f3n de los algoritmos de cach\u00e9 de flash de ese fabricante.
\nLa pr\u00e1ctica general de la pol\u00edtica de almacenamiento para un grupo de discos con nivel SSD es SSD first.
\nCach\u00e9 de Flash de Solo Lectura.<\/i> Para un cach\u00e9 de solo lectura, el nivel de almacenamiento en SSD aparece con una significativa localizaci\u00f3n de las operaciones de escritura independientemente de la cach\u00e9.
\nCach\u00e9 de Flash de Lectura \/ Escritura.<\/i> En el caso de un cach\u00e9 de flash en escritura, primero se establece el volumen m\u00e1ximo de la cach\u00e9, y el nivel de almacenamiento en SSD aparece solo cuando el tama\u00f1o de la cach\u00e9 no es suficiente para manejar toda la carga localizada.
\nEl c\u00e1lculo del rendimiento de SSD y cach\u00e9 se realiza cada vez seg\u00fan las recomendaciones del fabricante, pero siempre para el peor caso.
\n
Fuente: 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\udd47Dise\u00f1o de un centro de datos virtualizado | ProHoster","description":"Introducci\u00f3n al sistema de informaci\u00f3n desde el punto.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/35800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=35800"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/35800\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/26806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=35800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=35800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=35800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}