TI es un aspecto esencial de cualquier empresa hoy en día. El departamento de TI es responsable del desarrollo y las operaciones de las aplicaciones de software que respaldan los procesos comerciales. La mayoría de las empresas solían construir centros de datos privados en las instalaciones para alojar estas aplicaciones. Por el contrario, las empresas modernas desarrollan toda su infraestructura de TI en la nube pública. En este blog, analizaremos cómo diseñar un departamento de TI de tamaño mediano en Azure.
La infraestructura del departamento de TI que vamos a construir consta de 5 servidores bare-metal, tres máquinas virtuales y tres bases de datos.
Bloques de construcción arquitectónicos
Microsoft Azure tiene una gama completa de servicios para construir nuestra infraestructura. Veamos cómo los vamos a utilizar para satisfacer nuestros requisitos.
Servidores bare-metal
Si bien la virtualización aporta agilidad, todavía tenemos algunas aplicaciones empresariales que no están diseñadas para máquinas virtuales. Por lo tanto, los servidores bare-metal siguen siendo un requisito obligatorio en nuestros centros de datos.
Azure ofrece una amplia gama de tipos de servidores completos con opciones de almacenamiento NFS, ISCSI, o Canal de fibra. Este almacenamiento consta de SSD y NVMe discos
Aunque la mayoría de las aplicaciones empresariales no hacen un uso intensivo del ancho de banda, los servidores completos de Azure tienen 40/100G NIC para adaptarse a casos de uso de alto rendimiento. Un servidor sin sistema operativo se puede conectar a una red virtual de Azure similar a una máquina virtual, por lo que las cargas de trabajo sin sistema operativo pueden comunicarse de forma segura con otros recursos de Azure.
Podemos instalar el sistema operativo Windows o Linux en servidores sin sistema operativo de Azure obteniendo las licencias del sistema operativo nosotros mismos. También obtenemos acceso de root a los servidores bare-metal para que podamos tener un control completo sobre ellos.
máquinas virtuales
Las máquinas virtuales son un componente clave en la infraestructura de TI. Son mucho más rentables que los servidores bare-metal, por lo que tenemos la intención de utilizar máquinas virtuales para todas las aplicaciones de propósito general en nuestro departamento de TI.
Azure ofrece una variedad de máquinas virtuales, desde una sola vCPU hasta 416 vCPU. Azure también ofrece variantes de máquina virtual con una alta proporción de CPU a memoria y otras variantes con altas proporciones de memoria a CPU. Por lo tanto, podemos seleccionar el tipo de máquina virtual más eficiente que se adapte a nuestras necesidades. También podemos aprovisionar máquinas virtuales con GPU para aplicaciones especializadas, como análisis de video.
Las máquinas virtuales de Azure admiten el sistema operativo Windows y una variedad de distribuciones de Linux, como RHEL, CentOS, Ubuntu y SUSELinux.
Azure también proporciona almacenamiento en bloque para máquinas virtuales a través de discos administrados de Azure. Internamente, estos discos administrados implementan alta disponibilidad mediante la creación de tres réplicas, por lo que nuestros datos permanecen intactos en caso de fallas de hardware.
Redes
Azure tiene una solución de red sólida para construir una red privada segura para la comunicación entre máquinas virtuales, servidores completos y servicios como bases de datos. Azure Virtual Network, también llamada VNet, es el componente fundamental de esta solución de red.
Una red virtual se puede considerar como una red IP privada lógica dentro de Azure. Una red virtual está dedicada a un inquilino y nunca se comparte entre varios inquilinos. Una red virtual puede incluir varias subredes de IP. Los recursos, como las máquinas virtuales, se pueden conectar a estas subredes a través de interfaces de red virtual.
La red virtual también nos permite exponer de forma segura las máquinas virtuales y los servidores completos a Internet a través de Azure Firewall o Azure Application Gateway.
A menudo, los recursos en la nube se implementan en múltiples Regiones de Azure para lograr la redundancia geográfica. Con el emparejamiento de Azure Global VNet, podemos establecer un canal de comunicación seguro entre todos estos recursos en varias regiones de Azure. El emparejamiento de Global VNet se basa en una red troncal privada propiedad de Microsoft, por lo que no tenemos que preocuparnos por la seguridad.
bases de datos
Las bases de datos son un componente obligatorio en un centro de datos de TI. En un centro de datos local, configurar y operar una base de datos podría costar mucho tiempo y esfuerzo. Pero los servicios de base de datos administrados en Azure pueden aliviar esta carga.
Azure ofrece versiones administradas de motores de bases de datos relacionales de código abierto populares, como MySQL, MariaDB y PostgreSQL. También existe Azure SQL Database, que es un servicio de base de datos relacional diseñado para la nube. En comparación con las bases de datos de código abierto, Base de datos Azure SQL tiene mejor escalabilidad. Una instancia de Azure SQL Server se puede escalar hasta 8 TB para atender demandas de gran capacidad.
Para aplicaciones que requieren bases de datos NoSQL, usamos Azure Cosmos DB. Cosmos DB puede escalar para manejar grandes cargas de trabajo mientras mantiene un tiempo de respuesta constante de un solo dígito. También ofrece API compatibles con Apache Cassandra y MongoDB para migrar cualquier aplicación existente a CosmosDB, con cambios mínimos en el nivel de código.
Almacenamiento de archivos
Una empresa necesita almacenar una amplia variedad de datos estructurados y no estructurados. Azure proporciona varias soluciones de almacenamiento para este fin.
Azure Files es una solución de almacenamiento de archivos para almacenar documentos e imágenes. Se puede acceder a los objetos almacenados a través del protocolo SMB. Para almacenar grandes volúmenes de datos no estructurados, Azure Blob Storage es más adecuado.
Recuperación de desastres
La recuperación ante desastres es una responsabilidad importante en TI. Debemos diseñar nuestra infraestructura de TI para garantizar una recuperación rápida de fallas para garantizar la continuidad del negocio. En Azure, debemos considerar la recuperación ante desastres por separado para aplicaciones y bases de datos.
Para comprender la implementación de redundancia y recuperación ante desastres en Azure, debemos estar familiarizados con regiones y zonas de disponibilidad. Una región de Azure es un área geográfica que consta de varios centros de datos conectados a través de una red de baja latencia. Azure tiene múltiples regiones de este tipo en diferentes ubicaciones geográficas en todo el mundo. Una zona de disponibilidad es un centro de datos físicamente separado dentro de una región. Una región puede tener una o más zonas de disponibilidad.
Recuperación ante desastres para aplicaciones
Para las aplicaciones que se ejecutan en máquinas virtuales, podemos implementar la redundancia creando manualmente una réplica de la máquina virtual en una zona o región de disponibilidad separada. Luego, la aplicación se puede implementar en ambas máquinas virtuales para ejecutarse en un modo de espera activo.
Como alternativa, podemos usar Azure Site Recovery para implementar la redundancia geográfica para máquinas virtuales. Azure Site Recovery garantiza que nuestras máquinas virtuales y servidores completos se repliquen en otra ubicación para cambiar en caso de que no se puedan seguir usando las aplicaciones.
Para las aplicaciones que implementamos en varias regiones, podemos usar Azure Front Door como punto de entrada para nuestros usuarios. Azure Front Door puede enrutar el tráfico a las aplicaciones activas y en espera mediante un mecanismo de prioridad para que los usuarios cambien automáticamente al modo en espera si la configuración activa deja de estar disponible.
Recuperación de desastres para bases de datos
Los diferentes servicios de base de datos en Azure implementan la alta disponibilidad de formas únicas. Azure CosmosDB implementa alta disponibilidad mediante la replicación de datos en las regiones de Azure. Azure SQL Database usa Azure Blob Storage, que tiene funciones integradas de alta disponibilidad. PostgreSQL en Azure usa el almacenamiento de Azure para almacenar datos. Este almacenamiento incluye tres copias de sus datos dentro de una región para garantizar una alta disponibilidad. Para mejorar aún más la alta disponibilidad de PostgreSQL en Azure, podríamos usar réplicas de lectura. Luego, en caso de falla en la base de datos principal, podríamos cambiar a la réplica.
Respaldo
La copia de seguridad es otro aspecto importante de la recuperación ante desastres. Se debe establecer un mecanismo de respaldo adecuado además de la arquitectura de redundancia geográfica. Puede ayudar a la recuperación de la corrupción de datos, eliminación accidental, etc.
Azure Backup es un servicio fácil de configurar que puede realizar copias de seguridad de máquinas virtuales y bases de datos. Tiene una función para obtener copias de seguridad incrementales periódicas para optimizar los requisitos de almacenamiento para nuestras copias de seguridad.
Seguridad de la red
Azure VNet nos proporciona un entorno lógicamente aislado para implementar nuestros recursos. Al elegir usar VNet, nos aseguramos de que el tráfico interno entre aplicaciones permanezca en una red privada segura y no esté expuesto al público. Permitimos que el tráfico externo llegue solo a los recursos seleccionados en nuestro DC.
Como siguiente nivel de protección de la red, usamos los grupos de seguridad de red de Azure. Un grupo de seguridad de red actúa como un cortafuegos con estado para nuestros recursos. Un grupo de seguridad de red puede incluir varias reglas de seguridad que pueden permitir o denegar el tráfico según el protocolo y la dirección IP de origen/destino. Usamos grupos de seguridad de red con una regla de denegación predeterminada y solo permitimos tráfico específico entre nuestros recursos.
Usamos Azure Firewall, que es una solución de firewall de red de Azure para proteger nuestros recursos virtuales. El firewall de la red actúa como un firewall perimetral para bloquear el tráfico no deseado a nuestros recursos virtuales. Este cortafuegos también es compatible con SNAT. Entonces podemos proporcionar conectividad a Internet para nuestras máquinas virtuales a través del firewall.
Resumen de diseño
Como ya se mencionó, nuestra infraestructura de TI en Azure consta de 5 servidores completos, 3 máquinas virtuales y 3 bases de datos.
Implementamos nuestros recursos en dos regiones de Azure con las aplicaciones funcionando en modo activo-en espera. Usamos Puerta principal azul para que los usuarios puedan enrutarse sin problemas a la región en espera si se produce una interrupción en la región activa. Esto garantiza la recuperación ante desastres con un impacto mínimo para nuestros usuarios.
Para conectar de forma segura nuestros recursos dentro de una región, usamos Azure VNet. La conectividad entre las dos regiones se crea con el emparejamiento de Azure Global VNet. Esto nos permite conectar los recursos en las dos regiones sin VPN ni NAT.
En cada región, creamos subredes separadas para cada uno de nuestros servicios. Conectamos las máquinas virtuales a estas subredes a través de NIC virtuales. Los servidores de la base de datos están conectados a las subredes de la red virtual a través de puntos de conexión de servicio de la red virtual de Azure. Las instancias completas también están conectadas a la misma red virtual.
Usamos PostgreSQL como nuestra base de datos relacional con leer replicación entre regiones. Para aplicaciones que usan bases de datos NoSQL, usamos Cosmos DB. Creamos Cosmos DB con replicación en nuestras dos regiones, por lo que podemos cambiar instantáneamente en caso de falla sin pérdida de datos.
Implementamos la instancia de Azure Firewall en cada región para conectar nuestras máquinas virtuales y servidores bare-metal a Internet a través de NAT.
Conclusión
Usando los servicios discutidos de Azure, podemos implementar un centro de datos de TI seguro y totalmente redundante completamente en Azure sin depender de un centro de datos local.
ES 
EN