Last Updated on 22 agosto, 2017 by
Cuando encaramos un proyecto de IaaS, existe una falsa creencia en muchas organizaciones y administradores de IT en que esto no requiere ningún tipo de planeamiento o proyecto que lo soporte.
Lejos de ello, en esta publicación vamos a presentar los lineamientos de diseño básicos para cualquier proyecto en la nube en relación a máquinas virtuales y almacenamiento, poniendo foco desde lo tecnológico en la tecnología Microsoft Azure.
¡Esperamos que lo disfruten y estamos en contacto!
Tabla de Contenidos
Introducción
Objetivo y Alcance
Esta publicación tiene como objetivo que las organizaciones, como así también sus administradores de IT, puedan tomar mejores decisiones al momento de encarar un proyecto de IaaS en alguna nube pública, y en particular en Microsoft Azure.
Todos los temas tratados aquí serán en alto nivel técnico, es decir que no entraremos en detalles de bajo nivel sobre el cómo hacer una determinada tarea o acción.
Audiencia
Este documento está dirigido a Consultores, Profesionales IT y personas que desarrollan tareas de Consultoría, Administración y Soporte o que simplemente están interesados en leer e investigar sobre la tecnología alcanzada por esta publicación.
Comentarios y Corrección de Errores
Hemos realizado nuestro mejor esfuerzo para no cometer errores, pero al fin y al cabo somos seres humanos. Si deseás reportar algún error o darnos feedback de qué te pareció esta publicación, por favor no dejes de comunicarte con nosotros a través de correo electrónico a la siguiente dirección: info@tectimes.net.
Desarrollo
¿Lineamientos de Diseño? What?
Como dijimos en la introducción, existe una falsa creencia en muchas organizaciones y administradores de IT en que un proyecto de nube en el modelo IaaS (Infraestructura como Servicio) no requiere ningún tipo de planeamiento o proyecto que lo soporte. En sí, la creencia es que «todo está resuelto, simplemente creo las máquinas y todo sale andando».
Lejos de ello, un proyecto serio de IaaS requiere planeamiento de todos los aspectos que lo involucran: aspectos de redes, seguridad, accesibilidad, operaciones, almacenamiento, etc etc etc. Por supuesto, seguramente no tendremos que estimar inversión de hardware, mantenimiento de ese hardware, y aspectos de la capa de virtualización, los cuales ya están resueltos por el proveedor de servicios recordando el modelo de responsabilidades que vemos en la siguiente imagen:
Decisiones y Tareas de Diseño
En relación a un proyecto IaaS con Microsoft Azure, debemos tener en cuenta algunas decisiones y tareas de diseño.
Entre las decisiones podemos comentar las siguientes:
- ¿Qué tipo de servicio de administración de discos vamos a utilizar? Las opciones son «Azure Managed Disks» o «Unmanaged Disks».
- ¿Qué tipo de almacenamiento necesita mi proyecto? Las opciones son «Standard» o «Premium».
- ¿Voy a requerir discos mayores a 1 TB?
- ¿Qué tipo de performance I/O van a necesitar mis cargas de trabajo?
- ¿Mi aplicación estará en Alta Disponibilidad? Por ende… ¿Tengo requerimientos de disponibilidad de almacenamiento por cubrir?
Entre las tareas de diseño (operativas) podemos identificar:
- Revisar requerimientos de I/O de mis aplicaciones, las cuales estarán alojadas dentro de las VMs. En relación a esto, contrastar los resultados versus el tipo de Storage Account a seleccionar.
- Acordar una nomenclatura para mis Storage Accounts.
Estas decisiones y tareas que acabamos de identificar son las más significativas a revisar durante el proyecto. Para ayudar a ello, vamos a concentrarnos en algunos lineamientos de diseño en relación al Storage de las VMs.
Lineamientos de Diseño
¿Azure Disks o Azure Managed Disks?
Los discos virtuales son una parte esencial en la generación de máquinas virtuales. En este sentido, la primer definición que tenemos que tomar es si vamos a utilizar el servicio de «Azure Managed Disks» o no:
- En el caso de «Unmanaged Disks» el administrador debe definir la o las cuentas de almacenamiento requeridas para alojar los archivos VHD para las máquinas virtuales. En el caso de escalar se debe llevar un control para no exceder los IOPS permitidos para una cuenta o alguno de los discos.
- En el caso de «Managed Disks» no existe esta limitación por la cuenta de almacenamiento ni existe necesidad de mantener cuentas de almacenamiento. Esta es la opción «recomendada» por el fabricante.
¿Multiple Storage Accounts?
En el caso de «Unmanaged Disks», debemos ocuparnos de la disponibilidad y resiliencia. En este sentido, si los equipos que estamos desplegando requieren alta disponibilidad para las aplicaciones, es decir que por cada rol de nuestra aplicación tenemos dos equipos virtuales, debemos ocuparnos que cada uno de los discos de los equipos virtuales estén en cuentas de almacenamiento separadas. ¿Por qué? Porque no estaríamos cumpliendo con el requisito de alta disponibilidad si ubicamos ambas máquinas en la misma cuenta de almacenamiento.
En este sentido, un ejemplo de un rol WEB con dos instancias de máquinas virtuales en relación a su almacenamiento sería el siguiente:
- Servidor1 -> CuentaDeAlmacenamiento1
- Servidor2 -> CuentaDeAlmacenamiento2
¿Standard o Premium Storage?
Existen dos tipos de cuentas de almacenamiento soportadas para máquinas virtuales:
- Standard: performance «normal». Recomendado para cargas de trabajo genéricas.
- Premium: alta performance, baja latencia para los discos y soporte para cargas de trabajo que requieran I/O intensivo. Esto es recomendado para cargas de trabajo como base de datos SQL Server y Clusters de SQL Server. No todos los modelos de equipos en Azure soportan almacenamiento Premium.
¿Discos Anidados?
En caso que tengamos que tener algún volumen en nuestros equipos virtuales que superen 1 TB de información, tenemos una limitación de tamaño máximo de archivo en el Storage de Azure. El almacenamiento de tipo Disk Blob soporta hasta 1024 GB máximos, por lo cual tendremos que pensar en alguna alternativa.
Para ello, debemos generar varios discos de 1 TB y configurarlos dentro de nuestro sistema como «Striped Disks». Esto no solo ayuda a superar el límite de 1 TB de tamaño, sino que además nos permite sumar IOPS si nuestra aplicación requiere mayor intensidad para operaciones I/O.
En este sentido, los lineamientos de diseño recomendados son:
- Generar discos en el tamaño máximo de 1 TB desde la consola de Azure.
- Configurar y adjuntar la mayor cantidad de discos de 1TB en el sistema operativo, de esta forma se maximiza el espacio y los IOPS.
- Utilizar Storage Spaces en el sistema operativo.
- Deshabilitar la política de cache en los discos (caching policy = None).
Conclusiones
Como hemos podido observar, el diseño de la infraestructura de almacenamiento es vital para un proyecto exitoso IaaS en Azure, y podríamos decir en cualquier proveedor de servicios de nube.
Esperamos que esta publiación les haya resultado de interés. ¡Saludos!
Referencias y Links
- Azure Storage Clients: https://docs.microsoft.com/en-us/azure/storage/storage-explorers
- Azure Storage Service REST API Reference: https://msdn.microsoft.com/library/azure/dd179355.aspx
- Azure Storage Shared Access Signatures: https://docs.microsoft.com/en-us/azure/storage/storage-dotnet-shared-access-signature-part-1
Acerca del Autor
- [Evento] Microsoft Azure | Tendencias Digitales 2019 – 26/03/2019 - 30 marzo, 2019
- [Evento] Microsoft Azure | Tendencias Digitales 2019 – 06/02/2019 - 12 febrero, 2019
- [Evento] Microsoft Azure | Modernización de Apps con la Nube de Azure – 20/12/2018 - 22 diciembre, 2018
Sobre el ejemplo de servidores webs, si tuviera 2 servidores en una misma cuenta de almacenamiento, pero dentro de un conjunto de disponibilidad, estaría cumpliendo con la alta disponibilidad????