Introdución
Un sistema de información desde o punto de vista do usuario está ben definido en GOST RV 51987: "un sistema automatizado, cuxo resultado é a presentación da información de saída para o seu uso posterior". Se consideramos a estrutura interna, entón en esencia calquera IS é un sistema de algoritmos interconectados implementados en código. Nun sentido amplo da tese Turing-Church, un algoritmo (ou IS) transforma un conxunto de datos de entrada nun conxunto de datos de saída.
Mesmo podería dicirse que a transformación dos datos de entrada é o significado da existencia dun sistema de información. En consecuencia, o valor do IS e todo o complexo IS determínase a través do valor dos datos de entrada e saída.
En base a isto, o deseño debe comezar e estar baseado en datos, adaptando a arquitectura e os métodos á estrutura e á importancia dos datos.
Datos almacenados
Unha etapa clave na preparación para o deseño é a obtención das características de todos os conxuntos de datos previstos para o seu procesamento e almacenamento. Estas características inclúen:
- Volume de datos;
— Información sobre o ciclo de vida dos datos (crecemento de novos datos, vida útil, procesamento de datos obsoletos);
— Clasificación dos datos dende o punto de vista impacto no negocio principal da empresa (a tríada de confidencialidade, integridade e dispoñibilidade) xunto cos indicadores financeiros (por exemplo, o custo da perda de datos na última hora);
— Xeografía do tratamento de datos (localización física dos sistemas de procesamento);
— Requisitos regulamentarios para cada clase de datos (por exemplo, Federal Law-152, PCI DSS).
Sistemas de información
Os datos non só se almacenan, senón que tamén se procesan (transforman) polos sistemas de información. O seguinte paso despois de obter as características dos datos é o inventario máis completo dos sistemas de información, as súas características arquitectónicas, as interdependencias e os requisitos de infraestrutura en unidades convencionais para catro tipos de recursos:
- Potencia de cálculo do procesador;
- Cantidade de RAM;
— Requisitos para o volume e o rendemento do sistema de almacenamento de datos;
— Requisitos da rede de transmisión de datos (canles externas, canles entre compoñentes do IS).
Neste caso, debe haber requisitos para cada servizo/microservizo como parte do SI.
Por separado, é necesario ter en conta que, para un deseño correcto, é obrigatoria a dispoñibilidade de datos sobre o impacto do IS no negocio principal da empresa en forma de custo do tempo de inactividade do IS (rublos por hora).
Modelo de ameaza
Debe existir un modelo formal de ameazas desde o que se prevé protexer os datos/servizos. Ademais, o modelo de ameazas inclúe non só aspectos de confidencialidade, senón tamén de integridade e dispoñibilidade. Eses. Por exemplo:
— Fallo do servidor físico;
— Fallo do interruptor da parte superior do bastidor;
— Interrupción da canle de comunicación óptica entre centros de datos;
— Avaría de todo o sistema operativo de almacenamento.
Nalgúns casos, os modelos de ameazas están escritos non só para compoñentes de infraestrutura, senón tamén para sistemas de información específicos ou os seus compoñentes, como un fallo de DBMS con destrución lóxica da estrutura de datos.
Todas as decisións dentro do proxecto para protexer contra unha ameaza non descrita son innecesarias.
Requisitos regulamentarios
Se os datos que se tratan están suxeitos a regras especiais establecidas polos reguladores, requírese información sobre conxuntos de datos e normas de tratamento/almacenamento.
Obxectivos RPO/RTO
Deseñar calquera tipo de protección require ter indicadores de perda de datos obxectivo e tempo de recuperación do servizo obxectivo para cada unha das ameazas descritas.
Idealmente, RPO e RTO deberían ter asociados custos de perda de datos e tempo de inactividade por unidade de tempo.
División en grupos de recursos
Despois de recoller toda a información de entrada inicial, o primeiro paso é agrupar conxuntos de datos e IP en grupos baseados en modelos de ameazas e requisitos regulamentarios. O tipo de división de varias agrupacións determínase: mediante programación a nivel de software do sistema ou fisicamente.
Exemplos:
— O circuíto de tratamento de datos persoais está completamente separado fisicamente doutros sistemas;
— As copias de seguranza almacénanse nun sistema de almacenamento separado.
Neste caso, os pools poden ser incompletamente independentes, por exemplo, defínense dous pools de recursos informáticos (potencia do procesador + RAM), que usan un único pool de almacenamento de datos e un único pool de recursos de transmisión de datos.
Potencia de procesamento
Resumo, os requisitos de potencia de procesamento dun centro de datos virtualizado mídense en función do número de procesadores virtuais (vCPU) e da súa relación de consolidación en procesadores físicos (pCPU). Neste caso particular, 1 pCPU = 1 núcleo de procesador físico (excluíndo Hyper-Threading). O número de vCPU súmase en todas as agrupacións de recursos definidas (cada unha delas pode ter o seu propio factor de consolidación).
O coeficiente de consolidación dos sistemas cargados obtense empiricamente, en función da infraestrutura existente, ou mediante instalacións piloto e probas de carga. Para os sistemas descargados, utilízase a "práctica recomendada". En concreto, VMware cita a relación media como 8:1.
RAM
O requisito total de RAM obtense mediante unha simple suma. Non se recomenda usar a subscrición excesiva de RAM.
Recursos de almacenamento
Os requisitos de almacenamento obtéñense simplemente sumando todos os pools por capacidade e rendemento.
Os requisitos de rendemento exprésanse en IOPS combinados cunha relación de lectura/escritura media e, se é necesario, unha latencia de resposta máxima.
Os requisitos de calidade de servizo (QoS) para grupos ou sistemas específicos deben especificarse por separado.
Recursos da rede de datos
Os requisitos da rede de datos obtéñense simplemente sumando todos os conxuntos de ancho de banda.
Os requisitos de calidade de servizo (QoS) e latencia (RTT) para grupos ou sistemas específicos deben especificarse por separado.
Como parte dos requisitos para os recursos da rede de datos, tamén se indican os requisitos de illamento e/ou cifrado do tráfico de rede e mecanismos preferidos (802.1q, IPSec, etc.).
Selección de arquitectura
Esta guía non analiza ningunha opción que non sexa a arquitectura x86 e a virtualización do servidor 100%. Polo tanto, a elección da arquitectura do subsistema informático redúcese á elección da plataforma de virtualización do servidor, o factor de forma do servidor e os requisitos xerais de configuración do servidor.
O punto clave de elección é a certeza de utilizar un enfoque clásico con separación de funcións de procesamento, almacenamento e transmisión de datos ou converxente.
arquitectura clásica implica o uso de subsistemas externos intelixentes para almacenar e transmitir datos, mentres que os servidores só contribúen a potencia de procesamento e a memoria RAM ao conxunto común de recursos físicos. En casos extremos, os servidores vólvense completamente anónimos, tendo non só os seus propios discos, senón nin sequera un identificador do sistema. Neste caso, o SO ou o hipervisor cárgase desde un medio flash integrado ou desde un sistema de almacenamento de datos externo (inicio desde SAN).
No marco da arquitectura clásica, a elección entre láminas e bastidores realízase principalmente baseándose nos seguintes principios:
— Rentable (de media, os servidores de montaxe en rack son máis baratos);
— Densidade computacional (maior para as láminas);
— Consumo de enerxía e disipación de calor (as aspas teñen unha unidade específica máis alta por unidade);
— Escalabilidade e controlabilidade (as láminas xeralmente requiren menos esforzo para grandes instalacións);
- Uso de tarxetas de expansión (elección moi limitada para as láminas).
Arquitectura converxente (tamén coñecido como hiperconverxentes) implica a combinación das funcións de tratamento e almacenamento de datos, o que leva ao uso de discos de servidores locais e, como consecuencia, ao abandono do clásico factor de forma blade. Para sistemas converxentes, utilízanse servidores en rack ou sistemas de clúster, combinando varios servidores blade e discos locais nun só caso.
CPU/Memoria
Para calcular correctamente a configuración, cómpre comprender o tipo de carga para o ambiente ou cada un dos clústeres independentes.
CPU vinculada – un ambiente limitado no seu rendemento pola potencia do procesador. Engadir RAM non cambiará nada en canto ao rendemento (número de máquinas virtuales por servidor).
Memoria ligada - ambiente limitado pola memoria RAM. Máis memoria RAM no servidor permítelle executar máis máquinas virtuales no servidor.
GB / MHz (GB / pCPU): a relación media de consumo de RAM e potencia do procesador por esta carga en particular. Pódese usar para calcular a cantidade de memoria necesaria para unha actuación determinada e viceversa.
Cálculo de configuración do servidor
En primeiro lugar, cómpre determinar todos os tipos de carga e decidir sobre combinar ou dividir diferentes grupos de computación en diferentes clústeres.
A continuación, para cada un dos clústeres definidos, determínase a relación GB/MH cunha carga coñecida de antemán. Se a carga non se coñece de antemán, pero hai unha comprensión aproximada do nivel de utilización da potencia do procesador, podes usar as relacións estándar vCPU:pCPU para converter os requisitos do grupo en físicos.
Para cada clúster, divide a suma dos requisitos do grupo de CPU vCPU polo coeficiente:
vCPUsum / vCPU:pCPU = pCPUsum: número necesario de unidades físicas. núcleos
pCPUsum / 1.25 = pCPUht: número de núcleos axustado para Hyper-Threading
Supoñamos que é necesario calcular un clúster con 190 núcleos / 3.5 TB de RAM. Ao mesmo tempo, aceptamos unha carga obxectivo do 50% da potencia do procesador e do 75% da RAM.
pCPU
190
CPU util
50%
memoria
3500
Utilidade Mem
75%
Soquete
Núcleo
Srv/CPU
Srv Mem
Srv/Mem
2
6
25,3
128
36,5
2
8
19,0
192
24,3
2
10
15,2
256
18,2
2
14
10,9
384
12,2
2
18
8,4
512
9,1
Neste caso, sempre usamos o redondeo cara arriba ao enteiro máis próximo (=ROUNDUP(A1;0)).
A partir da táboa faise obvio que varias configuracións de servidor están equilibradas para os indicadores de destino:
— 26 servidores 2*6c / 192 GB
— 19 servidores 2*10c / 256 GB
— 10 servidores 2*18c / 512 GB
A elección destas configuracións debe facerse en función de factores adicionais, como o paquete térmico e a refrixeración dispoñible, os servidores xa utilizados ou o custo.
Características da elección dunha configuración de servidor
Máquinas virtuales amplas. Se é necesario aloxar máquinas virtuales amplas (comparable a 1 nodo NUMA ou máis), recoméndase, se é posible, seleccionar un servidor cunha configuración que permita que estas máquinas virtuales permanezan dentro do nodo NUMA. Cun gran número de máquinas virtuales amplas, existe o perigo de fragmentación dos recursos do clúster e, neste caso, selecciónanse servidores que permiten colocar máquinas virtuales amplas o máis densamente posible.
Tamaño do dominio dun único fallo.
A elección do tamaño do servidor tamén se basea no principio de minimizar o único dominio de fallo. Por exemplo, ao elixir entre:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
En igualdad de condicións, debes escoller a segunda opción, xa que cando un servidor falla (ou se está a manter), non se perden o 33% dos recursos do clúster, senón o 17%. Do mesmo xeito, redúcese á metade o número de VM e IS afectados polo accidente.
Cálculo de sistemas de almacenamento clásicos en función do rendemento
Os sistemas de almacenamento clásicos calcúlanse sempre utilizando o peor dos casos, excluíndo a influencia da caché operativa e a optimización das operacións.
Como indicadores básicos de rendemento, tomamos o rendemento mecánico do disco (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS
A continuación, o número de discos do grupo de discos calcúlase mediante a seguinte fórmula: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Onde:
- Total de IOPS – rendemento total necesario en IOPS do grupo de discos
- RW – porcentaxe de operacións de lectura
- Bolígrafo RAID – Penalización de RAID para o nivel RAID seleccionado
Lea máis sobre o dispositivo RAID e a penalización de RAID aquí - и и
En función do número de discos resultante, calcúlanse opcións posibles que cumpran os requisitos de capacidade de almacenamento, incluídas as opcións con almacenamento multinivel.
O cálculo dos sistemas que usan SSD como capa de almacenamento considérase por separado.
Características dos sistemas de cálculo con Flash Cache
caché flash – un nome común para todas as tecnoloxías propietarias para usar a memoria flash como caché de segundo nivel. Cando se usa unha caché flash, o sistema de almacenamento adoita calcularse para proporcionar unha carga constante dos discos magnéticos, mentres que o pico é atendido pola caché.
Neste caso, é necesario comprender o perfil de carga e o grao de localización do acceso aos bloques de volumes de almacenamento. A caché Flash é unha tecnoloxía para cargas de traballo con consultas moi localizadas e practicamente non se pode aplicar para volumes cargados uniformemente (como para sistemas de análise).
Cálculo de sistemas híbridos de gama baixa/media
Os sistemas híbridos das clases baixas e medias usan almacenamento de varios niveis con datos que se moven entre niveis nunha programación. Ao mesmo tempo, o tamaño do bloque de almacenamento de varios niveis para os mellores modelos é de 256 MB. Estas características non nos permiten considerar a tecnoloxía de almacenamento por niveis unha tecnoloxía para aumentar a produtividade, como moitas persoas cren erroneamente. O almacenamento multinivel en sistemas de clase baixa e media é unha tecnoloxía para optimizar os custos de almacenamento para sistemas con desniveles de carga pronunciados.
Para o almacenamento por niveis, calcúlase primeiro o rendemento do nivel superior, mentres que se considera que o nivel inferior de almacenamento só contribúe á capacidade de almacenamento que falta. Para un sistema híbrido de varios niveis, é obrigatorio utilizar a tecnoloxía de caché flash para o grupo de varios niveis para compensar a diminución do rendemento dos datos que se quentan de súpeto do nivel inferior.
Usando un SSD nun grupo de discos en capas
O uso de SSD nun grupo de discos multinivel ten variacións, dependendo da implementación específica dos algoritmos de caché flash por un fabricante determinado.
A práctica xeral da política de almacenamento para unha agrupación de discos cun nivel SSD é primeiro SSD.
Caché Flash de só lectura. Para unha caché flash de só lectura, a capa de almacenamento do SSD inclúe unha localización significativa das escrituras, independentemente da caché.
Ler/Escribir Flash Cache. No caso da caché flash, o tamaño da caché de escritura fíxase primeiro no tamaño máximo da caché e o nivel de almacenamento SSD só aparece cando o tamaño da caché é insuficiente para atender toda a carga de traballo localizada.
Os cálculos de rendemento da SSD e da caché realízanse cada vez en función das recomendacións do fabricante, pero sempre no peor dos casos.
Fonte: www.habr.com