Frias Rodrigo Tesina final ultimos comentarios RevisadoDGonzalez · 2019. 1. 9. · 8qlyhuvlgdg...

Universidad Técnica Federico Santa María Departamento de Informática

Magíster en Tecnologías de la Información

1

Evaluación de una Migración a Cloud Computing

Rodrigo Frias Toledo

Empresa Pacific Hydro Isidora Goyenechea 3520, Las Condes, Santiago

[email protected]

Resumen: Muchas empresas están migrando sus plataformas a Cloud, debido a los beneficios tangibles que presenta para el negocio. Entre estos se destacan: mayor escalabilidad, alta disponibilidad de servicio, menor inversión inicial y costos proporcionales a su utilización. Sin embargo, muchas compañías son reticentes a la hora de adoptar una estrategia de Cloud más agresiva, dados los obstáculos que enfrenta esta tecnología como son, la preocupación por la seguridad y la incompatibilidad de las aplicaciones actuales del negocio. La migración a Cloud, por otra parte, es un proyecto complejo con muchas variables y consideraciones. Si no es bien planificado y ejecutado puede poner en riesgo la continuidad operativa del negocio y producir gastos mayores. Se propone como solución a estas incertidumbres, que esta tesina concrete un caso real de análisis y migración a Cloud. Mediante esta propuesta se pretende validar la siguiente hipótesis: La migración a Cloud es más conveniente que permanecer en una infraestructura local. Con el análisis del resultado se establece una guía de buenas prácticas para la migración. Palabras Clave: Cloud, migración, seguridad, buenas prácticas

1 Introducción

Como parte de la ola de transformación digital, muchas empresas están migrando sus plataformas a Cloud. Según Forbes [Web-001] un 80% de las empresas están incluyendo Cloud en sus presupuestos IT en los próximos 2 años, con lo cual, la utilización de Cloud está pasando de ser una tendencia a transformarse en un estándar. El entusiasmo por su adopción es debido a los beneficios tangibles que presenta para el negocio, entre los cuales destacan: Mayor escalabilidad. Agilidad para responder a cambios en la demanda y rapidez en el despliegue de aplicaciones. La tecnología de Cloud permite incrementar o disminuir recursos de forma flexible. Por ejemplo, es posible implementar un nuevo servidor en minutos, o escalar los recursos de una plataforma en alta demanda de forma automática, manteniendo el desempeño sin impacto para el cliente o el usuario. En otros casos, es posible completar tareas de alto consumo de recursos de forma rápida y a tiempo, al escalar el poder de cómputo por determinados períodos. Menor inversión y costos proporcionales. Un modelo Cloud prácticamente elimina la necesidad de una inversión inicial en infraestructura, que en el caso de un modelo local, implica la implementación de una sala de servidores considerando que Chile es un país sísmico, con energía y respaldo eléctrico, sistemas de enfriamiento de aire, racks, servidores, equipamiento de respaldo y accesos de seguridad. En Cloud es posible reducir costos no solo en inversión sino también al pagar por uso en demanda. Esto se logra variando los recursos de cómputo en el tiempo de utilización, alcanzando un modelo de costos más eficiente. Alta disponibilidad. Un servicio Cloud de calidad se encuentra bajo estrictas normas y diseños que permiten alta disponibilidad y redundancia de forma intrínseca. Esta alta disponibilidad se traduce también en mejores servicios para usuarios y clientes. Los riesgos de fallos de una sala de servidores local se mitigan al transferirse al proveedor, el cual debe proveer alta disponibilidad según contrato con un SLA establecido (Service Level



2

Agreement). El nivel de abstracción de un Cloud permite además que las aplicaciones no se encuentren dependientes de un dispositivo o infraestructura en particular. En caso de un desastre, un Cloud de calidad se encontrará física y geográficamente respaldado.

1.1 Descripción del problema

Sin embargo, muchas compañías son reticentes a la hora de adoptar una estrategia de Cloud más agresiva. Entre los principales obstáculos que se enfrentan las compañías se encuentran:

1.1.1 Seguridad

Un servicio Cloud implica que la responsabilidad sobre los datos es compartida con el proveedor, lo cual aumenta la vulnerabilidad. En el caso de una Cloud pública implica ampliar el perímetro de seguridad e incluir al proveedor, desconociendo a cabalidad sus políticas de seguridad. En entornos compartidos, los datos se encuentran además con el riesgo de ser accedidos ya sea accidentalmente o de forma premeditada por terceros.

1.1.2 Incompatibilidad de aplicaciones

Es posible que aplicaciones de negocio que sean críticas estén impedidas de ser migradas a un Cloud por problemas técnicos, como aplicaciones heredadas en sistemas mainframe que no soportan entornos Cloud, o que la complejidad de su adaptación lo hagan muy riesgoso. Sistemas propietarios no creados para trabajar en Cloud, sistemas industriales que requieren protocolos especiales o que no han sido diseñados para entornos WAN.

1.1.3 Servicios Cloud de calidad

Una compañía puede tener estándares muy superiores a los que pudiese ofrecer un Cloud en cuanto a disponibilidad, performance y seguridad, que le impidan plantear este modelo. También puede ocurrir que los requerimientos sean muy particulares (por ejemplo, la capacidad requerida por un observatorio astronómico).

1.1.4 Políticas y leyes

Una empresa puede plantearse que la migración a Cloud sea en contra de sus políticas, al hacer su operación dependiente de un tercero. Puede ocurrir que una política o regulación impida que una aplicación crítica se encuentre fuera de las dependencias de la organización. También que la política de confidencialidad de la información sea vulnerada por la ubicación física del Cloud, por ejemplo, en el caso de Estados Unidos, pudiese permitirse el acceso a los datos privados al gobierno de los Estados Unidos amparándose en la ley patriota.

1.1.5 Migración

En cuanto a la migración de la infraestructura de una empresa a Cloud, no se trata de un proceso trivial; es un proyecto complejo con muchas variables, riesgos y consideraciones. Un proyecto de esta magnitud si no es bien diseñado y ejecutado puede poner en riesgo la continuidad operativa del negocio y producir más gastos que las inversiones estimadas en el proyecto, al no considerar por ejemplo, el crecimiento de la organización.

1.1.6 Ancho de banda, latencia y Jitter

Mayoritariamente en el caso de Cloud pública, es posible que los requerimientos de ancho de banda a través de Internet al país donde se encuentre hosteado el Cloud, sean una problemática. En otros casos, la latencia hacia el Cloud impida que las aplicaciones puedan funcionar de forma eficiente, más aun si se compara con el tiempo de respuesta obtenido en un servidor local. El Jitter es la inestabilidad de los paquetes de datos en el tiempo, ocasionado principalmente por enlaces lentos o congestionados. Puede provocar que las aplicaciones funcionen



3

erráticamente a diferentes horas del día, dado el medio compartido y no garantizado, afectando principalmente a comunicaciones que necesitan tiempo real (como VoIP).

1.2 Propuesta de solución

Como primera medida en un proyecto Cloud, se debe determinar qué servicios conviene migrarse a una nube, y analizar el tipo de Cloud que se debe considerar. Las opciones son variadas y dependen mucho del tipo de organización y servicio que prestan. A pesar del tipo de Cloud escogido, todas las opciones deben considerar la seguridad como un ingrediente vital. Además al existir diferentes alternativas de solución, es fácil perder la claridad del diseño que realmente se ajusta a la empresa y dejarse llevar a una alternativa que puede ser beneficiosa para el proveedor, pero no para la empresa. La continuidad operativa es otra variable importante a considerar, la cual ofrece preguntas como, si existirá una administración compartida o de responsabilidad del proveedor, en cuyo caso cuáles serán los SLAs comprometidos.

1.3 Objetivo General

El objetivo principal es analizar un proyecto de migración a Cloud, y siguiendo los pasos propuestos en la tesina, determinar si su implementación provee beneficios a la organización. Para ello se debe cumplir la hipótesis planteada en el proyecto. Si la hipótesis se valida correctamente, esta tesina se transforma en una guía de buenas prácticas para la implementación de un proyecto de migración a Cloud.

1.4 Objetivos Específicos

Otros objetivos son:

Implementar un proyecto de migración a Cloud. Identificar las etapas necesarias para realizar una migración exitosa. Generar conocimiento acerca de una migración a Cloud basado en una experiencia real. Conocer el estado del arte en relación a Cloud Computing.

1.5 Hipótesis

La hipótesis a comprobar es si la migración a Cloud otorga más beneficios que mantener una infraestructura local. Las variables Independientes (de control) y dependientes, son las que se presentan al negocio para determinar la viabilidad del proyecto:

Costos de la implementación y operación del proyecto versus los costos de la infraestructura actual. Riesgos al negocio que presenta la infraestructura actual, la disponibilidad actual de servicio versus lo

requerido por el negocio y que es parte de los requerimientos de Cloud. La capacidad de crecimiento de la infraestructura actual para enfrentar los nuevos desafíos y directrices del

negocio.

Tabla 1. Variables de la hipótesis.

KPI Variables independientes Variables Dependientes Costo Costos infraestructura local Costo implementación y operación de proyecto Riesgo Riesgos actuales Riesgos post-proyecto Crecimiento Capacidad de crecimiento actual Capacidad de crecimiento post-proyecto



4

1.5.1 Estrategia de validación

La validación de las hipótesis se realiza comparando el resultado del valor de las variables. El resultado de la comparación determina si el proyecto es o no viable. Los resultados esperados de la hipótesis son los siguientes: La variable que representa los costos de infraestructura local, debe ser mayor que el costo de inversión en

el proyecto. El valor esperado es que monto de inversión del proyecto implique un ahorro, comparando contra todos los costos que implica la infraestructura local. Este valor será en U$ por los años de inversión del proyecto.

Los riesgos a la continuidad operativa de la compañía posteriores a la implementación, deben ser menores que los riesgos de mantener la infraestructura actual.

- Disponibilidad de servicio. El porcentaje de disponibilidad de servicio se mide en horas por año. El Uptime Institute, otorga la siguiente categorización de Data Centers basado en la norma TIA-942:

TIER 1: Sin redundancia: 99,67%, 28,8 horas de interrupción al año TIER 2: Redundancia parcial: 99,75%, 22 horas de interrupción al año TIER 3: Redundancia N+1: 99,982%, 1,6 horas de interrupción al año TIER 4: Redundancia 2N+1: 99,995%, 0,8 horas de interrupción al año

La especificación del TIER deseado es una definición del negocio, dado que un TIER mayor aumenta el costo del proyecto. Cabe indicar que en Chile no existen Data Centers tipo TIER 4, dado que existe un solo proveedor de distribución eléctrica y contar con más de uno, es un requisito de TIER 4.

- RTO y RPO. Los valores de recuperación ante desastres. El RTO corresponde al tiempo en horas que el servicio es restaurado. El RPO el punto de respaldo de datos desde donde es posible recuperar la información luego del desastre, también medido en horas.

La capacidad de crecimiento y flexibilidad de servicios otorgados por el proyecto debe ser mayor que lo proporcionado por la infraestructura actual. El valor a medir corresponde a las capacidades en:

- Máquinas virtuales que puede soportar, basado en CPU y memoria, requerida para una máquina virtual estándar.

- Terabytes de almacenamiento - Costos asociados a la expansión de las capacidades basado en escenarios de crecimiento agresivos

indicados por el negocio. A priori se estimarán 2 escenarios de 50% y 100% de crecimiento agresivo.

2 Marco teórico

El marco teórico en el que se basa la Tesina el Cloud Computing, que se trata de la utilización de recursos computacionales como servicio. Esto es opuesto al enfoque tradicional que utiliza y comercializa la computación como producto, incluyendo los recursos clásicos de hardware (procesamiento, memoria y almacenamiento), y otros como el mismo software de virtualización, las plataformas y aplicaciones que corren sobre estas. Típicamente el servicio es entregado sobre internet o una red dedicada, dependiendo del tipo de Cloud.

Cloud pública: Se ofrece sobre Internet o una VPN. Una ventaja es su economía de pago por uso, su disponibilidad y elasticidad. Las desventajas son que sus capacidades son en general compartidas, y el medio de acceso es Internet, que típicamente no es garantizado. Además las plataformas son generalmente propietarias, haciendo compleja una migración a otro Cloud público.

Cloud privada: Se ofrece en general sobre un link privado y sus capacidades pueden ser dedicadas a un cliente específico. Poseen mayor poder de cómputo. Son escalables y de alta disponibilidad, pero su costo es en general superior a un Cloud público y están condicionados a contratos con plazos fijos.

Cloud híbrida: Es una mezcla entre una Cloud pública y privada para satisfacer diferentes niveles de servicio. Su administración y diseño pueden tornarse más complejos.



5

Community Cloud: Se trata de un tipo de Cloud orientado en general a SaaS (explicado más abajo) e involucra varias organizaciones, empresas, clientes y proveedores. Se menciona como concepto, pero no forma parte del alcance de este proyecto.

En cuanto a los servicios, en Cloud es posible encontrar las siguientes categorías:

Infraestructura como Servicio (IaaS): Servicio a partir de la capa de hardware (ya sea dedicado o compartido), donde las plataformas y aplicaciones de cliente pueden ser ejecutadas. De acuerdo a las condiciones contratadas, el cliente podría administrar los hosts y el almacenamiento. Común de encontrar en un Cloud privado.

Plataforma como Servicio (PaaS): Se entrega al cliente una plataforma previamente configurada donde puede correr sus aplicaciones. Se entrega tanto en Cloud privado como público.

Software como Servicio (SaaS): La infraestructura y aplicaciones se encuentran previamente implementadas por el proveedor. El cliente puede ejecutar sus procesos y sistemas o hacerlo para otros, pero no puede involucrarse en la plataforma o el hardware. Es más común encontrarlo en Cloud público.

El proyecto se basa principalmente en los conceptos de IaaS, utilizados como Cloud privada empresarial y Cloud pública. IaaS virtualiza el procesamiento, memoria, almacenamiento y conectividad y la ofrece como servicio privado a los clientes. La capacidad de cómputo se entrega a los clientes como máquinas virtuales como recursos dedicados. En cuanto a Cloud pública, estos recursos de cómputo son compartidos con otros clientes y administrados por el proveedor de Cloud en forma exclusiva. El cliente solo paga por los recursos que consume activamente en los períodos determinados de tiempo, pudiendo ser más económicamente viable en el caso de utilización esporádica.

2.1 Estado del arte

2.1.1 Cloud pública

La tendencia actual es una mayor utilización de Cloud públicas debido a la madurez de sus productos y en Chile específicamente, a su llegada con hosting locales, los cuales evitan problemas de latencia. Algunos ejemplos son Microsoft con su Azure Stack [Web-006]. Esta solución permite la combinación de Azure con el mundo privado a través de los Data Centers de GTD, obteniendo una Cloud híbrida en el entorno local. Microsoft tiene por su parte presencia en la región con su Data Center en Sao Paulo, Brasil. Google cuenta con su propio Data Center y es muy probable que Amazon realice una millonaria inversión en el país [Web-002] para comenzar los testeos de sus plataformas en la infraestructura de Chile, como hub para el resto de la región. Esto resuelve una de las problemáticas más importantes del Cloud público como es la latencia y la velocidad. La problemática actual está dada por la infraestructura propietaria que limita la migración entre Clouds, donde transferir Terabytes pudiese tomar semanas o meses.

2.1.2 Cloud Containers

Containers (o dockers) [Web-003] es la nueva tendencia de la industria. Se trata de un nuevo modelo de abstracción similar a una máquina virtual, sin embargo, con menos capas entre la aplicación y el hardware. En un entorno virtualizado tradicional el hypervisor interactúa con el OS y el hardware del host por una parte, y con el OS de la máquina virtual, proveyéndola de recursos. Sobre la VM se encuentran las librerías y finalmente la aplicación. En el caso de un container o docker, se trata de una capa basada en código libre, portable y auto contenida, que permite la abstracción de la aplicación y todas sus dependencias. La aplicación y sus librerías interactúan con el motor del container, quien interactúa directamente con el kernel del OS del host. Esto permite beneficios como una completa aislación de aplicaciones, despliegues extremadamente rápidos, elimina riesgos de seguridad del OS de la máquina virtual y recursos subutilizados.



6

Containers aplica con mayor énfasis en Clouds del tipo PaaS y SaaS. Es ideal para arquitecturas basadas en microservicios. Sin embargo, los nuevos OS como Microsoft Server 2016 incorporan containers en sus características. VMware por su parte ha facilitado la creación de containers dentro de las VMs y desarrollado el producto VIC para esta tendencia, obteniendo buenos resultados [Web-004]. Google es el creador de esta tecnología. Diseñó Kubernetes, el sistema orquestador de containers para sus aplicaciones, para luego donarlo a la Cloud Native Computing Foundation, transformándose así en Opensource. Este estándar es soportado en la actualidad por todos los proveedores de Cloud públicas o híbridas [Web-005].

2.1.3 Plataformas Multi-Cloud

Multi-Cloud es un enfoque en que la solución Cloud está compuesta por más de un proveedor, administrado a través de una plataforma única de un administrador de Multi-cloud a través de una herramienta única. Esto elimina otro de los problemas de las Cloud públicas, que es la complejidad para migrar entre ellas debido a que se basan en plataformas propietarias y permite sacar ventaja de las mejores características de cada proveedor de Cloud. La desventaja principal es un mayor costo al disminuir la economía de escala e incluir un partner especializado.

2.2 Proyectos similares

Existe variada literatura que compara la alternativa de mantener una infraestructura local contra una migración a Cloud, sin embargo, esta literatura no es agnóstica a las marcas. Algunos ejemplos de los títulos tienen relación con migraciones a Clouds públicas como Amazon Web Services (AWS) o Microsoft Azure, y otros específicos a SaaS o aplicaciones, como la guía de HP: “HP Application Migration to On-Premises Cloud” [Web-007]. Esta guía de HP provee los pasos para desarrollar un proyecto de migración a una Cloud privada. El documento plantea 5 fases en una etapa de migración:

Descubrimiento: Identificar componentes, carga de servidores, relaciones y dependencias. Como esto determinar qué tan preparada esta la infraestructura actual para una migración a Cloud, cual es la carga actual de aplicaciones y el mapeo de las tecnologías actuales. Adicionalmente, cual es la prioridad del negocio.

Idoneidad. Estudio de la carga de trabajo de las aplicaciones de acuerdo a estándares de la industria, lo que responderá a interrogantes como que carga de trabajo se moverá al Cloud, lo que deriva en el análisis de costos y beneficios y la tecnología requerida para la migración.

Mapping. Esta etapa permite determinar cuáles son las cargas de trabajo en las plataformas de destino, lo que determina además el tipo de Cloud a utilizar (privada, híbrida, pública) y los requerimientos de software y hardware.

Migración. Mover las cargas de trabajo desde el origen al destino. Este proceso ayuda a comprender la estrategia a utilizar, el nivel de automatización, los agentes y las prioridades, para evitar impactos al negocio.

Habilitación. La etapa final de la actividad es la validación de las conexiones, la seguridad, los niveles de servicio y el performance considerado previamente a la migración y mide el éxito del proyecto.

Existen otros documentos específicos de marcas, para planificación basadas en sus herramientas. Por ejemplo la Guía EMC “El camino de TI de EMC hacia la nube privada” [Web-008]. A nivel país, la literatura es bastante escasa y se encuentra principalmente a nivel académico. A nivel empresarial, Chile tiene un nivel de conocimiento básico en Cloud Computing, según detectó el estudio “Chile 4.0: Cloud Computing Y El Futuro De La Productividad” [Web-009] de Fundación Chile. Solo la mitad de los ejecutivos TI con poder de decisión conocen de Cloud y están dispuestos a adoptarla.



7

3 Desarrollo del proyecto

3.1 Empresa

La empresa escogida es Pacific Hydro, la unidad de negocio de Brasil. Con más de 20 años en el negocio de la energía renovable, desde el año 2006 construye y opera 2 parques eólicos en el nordeste por 58 MW, con capacidad para abastecer 200,000 hogares. En el año 2017 la empresa fue adquirida por la estatal China SPIC, y afines del mismo año realizó la adquisición de la central hidroeléctrica Sao Simão, con capacidad de 1,710 MW, aumentando el portafolio de Pacific Hydro Brasil en casi 30 veces. Este crecimiento explosivo obligó a un aumento del personal de la compañía de 25 a más de 150 personas en pocos meses. Procedimientos y procesos debieron ser creados rápidamente. La infraestructura IT creada para una pequeña empresa, claramente no es suficiente para este nuevo desafío. Por lo tanto, la estrategia de la compañía está orientada a soportar este crecimiento y preparar la compañía para incluso mayores desafíos.

3.2 Objetivos del proyecto

Los objetivos del proyecto se basan en la implementación de un proyecto Cloud que soporte este crecimiento:

Entregar a la compañía con la capacidad de cómputo que necesita para soportar su crecimiento Considerar las alternativas disponibles en el mercado que permitan flexibilidad y escalabilidad Soportar un potencial crecimiento exponencial Costos adecuados a la capacidad requerida, no creando infraestructura ociosa y gastos innecesarios

3.3 Servicios y sistemas actuales

Para presentar el proyecto al negocio, es necesario obtener la información de los servicios y sistemas actuales, para luego categorizarlos y estimar el impacto que significa para el negocio la falla o indisponibilidad de ellos. Con esta información es posible presentar a la gerencia tomar la decisión de contar o no con un entorno que permita mantener una alta disponibilidad de servicios. Las funciones del negocio cubiertas por los servicios y sistemas actuales, son identificadas en la siguiente tabla. En ella también se detallan los sistemas que se encuentra en proyecto (con el sufijo NEW) y que requieren infraestructura. Se listan únicamente aquellas que se pueden ver afectadas por el proyecto. Dado el crecimiento exponencial del negocio, se espera que muchas nuevas necesitadas aparezcan conformadas como nuevos sistemas.

Tabla 2. Principales sistemas del negocio de Pacific Hydro Brasil.

Business Function Description Hosting Hosted

in Shared /

Dedicated Type

Assets control Plants SCADA control system eolic parks/ dams on Premise Brasil Dedicated Server access

Collaboration Document share/ email/ workflows/ databases on Premise Brasil Dedicated Local Client

Compliance Generation visualization/ government regulations Cloud/ premise External Shared Server access

Corp Communication Phone system on Premise Brasil Dedicated Local Client

Energy Generation info Energy visualization/ data extraction on Premise Brasil Dedicated Server access

Financial processes Financial systems Cloud/ premise External Shared Web

IT base system Virtual environment/ network on Premise Brasil Dedicated Web/ Client



8

Mainteinance Plant mainteinance Cloud External Shared Web

Operations Metering/ sensors systems Cloud/ premise External Dedicated Web

Secure access Secure access sites and users (VPN) on Premise Brasil Dedicated Local Client

Secure information Local user backup on Premise Brasil Dedicated Local Client

Secure physical access Access control on Premise Brasil Dedicated Server access

Trading Energy trading analysis Cloud External Shared Web

Las funciones de los diferentes sistemas clasificados en la Tabla 2 son las siguientes:

Assets control: Control de activos en operación, como sistemas SCADA y de tele protecciones de líneas eléctricas.

Collaboration: Sistemas que permiten la colaboración e intercambio de información entre usuarios, como fileservers, intranets, telefonía y servidores de correo.

Compliance: Permiten cumplir con las regulaciones gubernamentales. Corp Communication: Sistemas de telefonía digital, satelital y VHF. Energy Generation info: Información de la generación de energía de los activos. Financial processes: Sistemas financieros para la operación y toma de decisiones. IT base system: Sistemas que son la base para el funcionamiento de los sistemas del negocio. Maintenance: Sistemas de planificación de mantenimiento de centrales y parques eólicos. Operations: Sistemas de medición y sensores para centrales y parques eólicos. Secure access: Proveen acceso seguro a aplicaciones y seguridad perimetral. Secure information: Sistemas de respaldo de información. Secure physical access: Sistemas de acceso a instalaciones. Trading: Analisis del mercado eléctrico para estimación de presupuestos.

3.4 Análisis de impacto

Los sistemas antes descritos proveen las funciones para que la compañía pueda operar. Dependiendo de su grado de criticidad en términos de soporte al negocio, su utilidad para la toma de decisiones y cumplir con las obligaciones legales, se pueden categorizar en una matriz de impacto al negocio en caso de una indisponibilidad de su servicio. Las funciones del negocio se muestran en esta matriz de acuerdo a diferentes escenarios que implican este impacto, y se clasifican por el período de tiempo que el negocio puede considerar su indisponibilidad como aceptable. Este tiempo se conoce como RTO (Recovery Time Objective). Al presentar esta matriz al negocio, es posible que tomar la decisión más certera que permita mantener la continuidad y eliminar o mitigar los riesgos, en base a las expectativas y las restricciones de tiempo y costo de las soluciones de infraestructura que pudiesen plantearse. Estas soluciones se plantean tomando en cuenta las alternativas disponibles en el mercado, las restricciones y condiciones del negocio y los requisitos y políticas emitidas por el área de IT. Se incluye la tabla en una hoja vertical para una mejor comprensión.



9

Tabla 3. Matriz de impacto de funciones y sistemas.

RTO (Recovery time objective) 1 As soon as possible 2 24 hours tolerance 3 2 to 3 days 4 4 to 10 days 5 11 to 29 days 6 Up to a month

When needs to be restore to How long before the

stop produces sanctions or legal issues

Other considerations when the function must be restored

Summary Avoid

financial loss

Avoid energy

generation stops

Provide support/ info

to other departments

Provide key

information to allow taking

decisions

Support to the

business leadership

To complain

with regulatory

market

To do not fulfill

contracts

To avoid employees

to leave

To avoid harm to people

Avoid a damage to the public

image/ reputation

Function System Service Support Management Legal People TOTAL

Assets control ABB Control 1 1 3 2 2 1 1 4 5 1 1

Assets control Wobben 1 1 3 2 2 1 1 4 5 1 1

Collaboration FTP 2 4 3 4 4 4 2

Collaboration DFS 3 2 2 3 4 4 2

Collaboration File Server 3 2 2 2 4 4 2

Collaboration SharePoint (new) 2 3 3 3 3 3 4 2

Collaboration Exchange 3 4 2 3 3 3 4 2

Collaboration DocuSign 3 2 3 5 5 2

Financial processes SAP S4 HANA (NEW) 2 2 3 6 6 2

IT base system VMWare 3 2 5 6 2

IT base system Cisco ISE 3 4 2 2

IT base system Active Directory 2 5 4 4 4 5 2

Secure access VPN Watchguard S2S 3 2 4 2

Compliance ABNT 3 3 3 3 3 5 3

Compliance ONS access 3 3 3 3 3 4 3

Corp Communication Cisco PBX 3 4 4 3 4 3

Energy info IDAS 3 4 4 3 3 3 4 4 3

Energy info Elipse 3 4 3 3 3 3 3 4 3

Energy info PHORM 3 4 3 3 3 3 3 4 3



10

Financial processes Fortes 3 5 3 3 3 3

Financial processes DELLOS 3 4 3 3 3 3 3 3 3

Corp Communication Cisco PBX SP 3 4 4 4 4 3

Corp Communication Cisco PBX SS 3 3 4 3 4 3

Corp Communication Cisco PBX RN 3 3 4 3 4 3

Financial processes Mastersaf DFE 3 5 4 3 3 3 4 4 3

Mainteinance Informa 3 4 3 4 5 4 4 5 3

Operations Way2 3 3 3 4 4 4 4 3

Operations Construserv 3 3 3 4 4 4 4 3

Secure access Terminal Server 3 4 4 4 3

IT base system DNS Windows 4 4 4 6 6 4

Secure access VPN Watchguard users 5 4 5 4 4

Trading Paradigma 5 4 4 4

Secure access LinOTP 5 5 5

Secure information Symantec DLO 5 5 5 6 6 5

Monitoring GTX app monit 5 6 5

Trading Plan4 5 6 5

Trading Decomp e Cepel 5 6 5

IT base system Cisco Prime 6 6

Secure information Symantec Backup Exec 6 6 6

Secure physical access Access control 6 6

Application Autocad Server 6 6 6

Automation Fusion 6 6

IT base system Sysaid 6 6 6

Secure physical access CCTV 6 6 6



11

Es posible comprender en la tabla anterior la relevancia de las diferentes funciones y sistemas asociados a estos. Se puede determinar que la importancia está ligada principalmente a la función, con lo cual se puede establecer una matriz de impacto mucho más sencilla de comprender y que puede ser asimilada por la gerencia de forma rápida y certera.

Sin embargo, el mayor beneficio es que se logra categorizar un nuevo sistema bajo esta matriz y comprender inmediatamente el impacto al negocio si este falla. De esta forma se puede establecer una política de implementación que tenga como requisito el RTO establecido por el negocio.

Tabla 4. Categorización de RTO por función.

Function RTO

Assets control As soon as possible

Collaboration 24 hours tolerance

Financial processes 24 hours tolerance

IT base system 24 hours tolerance

Secure access 24 hours tolerance

Compliance 2 to 3 days

Corp Communication 2 to 3 days

Energy Generation info 2 to 3 days

Operations 2 to 3 days

Maintenance 2 to 3 days

Trading 4 to 10 days

Secure information 11 to 29 days

Secure physical access Up to a month

Si bien la categorización del control de los activos es totalmente obvia, es interesante como las herramientas de colaboración destacan sobre otras funciones del negocio, incluso tratándose del marco regulatorio. Los sistemas IT parecen ser menos críticos de lo esperado, sin embargo, esto se explica por la disponibilidad de alternativas que pueden minimizar este riesgo. Cabe indicar que el entorno virtual VMWare, en la actualidad solo se utiliza para máquinas relacionadas con la telefonía IP. Extrapolando una falla de este sistema, su RTO aumenta a la categoría “2 a 3 días”.

Al tomar esta categorización y llevarla a al listado de sistemas de la compañía, se podrá identificar que muchos de los sistemas críticos se encuentran hosteados en servidores de infraestructura local. Con este análisis, se recomienda a los tomadores de decisión, permitir las acciones necesarias para proteger la compañía, elaborando un proyecto para evitar un desastre. Un análisis por sistema mostrará que un 80% de ellos no cumple con el estándar de alta disponibilidad requerido.



12

Tabla 5. Sistemas críticos hosteados en infraestructura local Business Function System Name Description Hosting BIA Current Status

Assets control ABB Control SCADA control system on Premise As soon as possible As soon as possible

Assets control Wobben Eolic park control on Premise As soon as possible 24 hours tolerance

Collaboration FTP File transfer server on Premise 24 hours tolerance 2 to 3 days

Collaboration DFS Distributed fileserver on Premise 24 hours tolerance 4 to 10 days

Collaboration File Server Share fileserver on Premise 24 hours tolerance 11 to 29 days

Collaboration SharePoint (NEW) Document management on Premise 24 hours tolerance 24 hours tolerance

Collaboration Exchange Email server on Premise 24 hours tolerance 2 to 3 days

Corp Communication Cisco PBX Phone system on Premise 2 to 3 days 2 to 3 days

Generation info IDAS Data adquisition PLC on Premise 2 to 3 days 4 to 10 days

Generation info Eclipse Energy visualization on Premise 2 to 3 days 2 to 3 days

Financial processes Fortes Financial system on Premise 2 to 3 days 4 to 10 days

Generation info PHORM Data visualization on Premise 2 to 3 days 4 to 10 days

IT base system VMWare Virtual environment on Premise 4 to 10 days 4 to 10 days

IT base system DNS Windows Domain name resolution on Premise 4 to 10 days 4 to 10 days

IT base system Active Directory Users database on Premise 4 to 10 days 4 to 10 days

Secure access VPN Watchguard External access on Premise 4 to 10 days 4 to 10 days

Secure access Alarm system Alarm system on Premise 4 to 10 days 4 to 10 days

Secure access LinOTP Second factor auth on Premise 4 to 10 days 4 to 10 days

Secure information Symantec DLO Local user backup on Premise 11 to 29 days 11 to 29 days

Secure information Symantec Backup Data backup server on Premise 11 to 29 days 11 to 29 days

Secure physical access Access control Building access on Premise Up to a month Up to a month

3.5 Análisis de los tipos de Cloud

El análisis BIA muestra que los sistemas más críticos de la compañía se encuentran hosteados sobre entornos locales. La columna que muestra el estado actual, indica que estos se encuentran sin la redundancia y disponibilidad de servicio requerida por el negocio, transformándose en un riesgo. Por ejemplo, el sistema de control del parque eólico tiene un requerimiento de ser recuperado en tiempo real, sin embargo, la capacidad actual es mayor a 24 horas. Dado que estos sistemas se encuentran en entornos de hardware local, la solución idónea es un entorno de Cloud privado con alta disponibilidad o que cuente con un DRS (Disaster Recovery System), que cumpla con la disponibilidad requerida.

3.6 Requerimientos técnicos para la propuesta

Se realiza un análisis de las capacidades necesarias y su escalabilidad de acuerdo a los requerimientos de cómputo de los sistemas actuales y las estimaciones de crecimiento futuras del negocio. Los requerimientos solicitados a los proveedores son los siguientes:



13

3.6.1 Data Centers

Data Center: Debe estar construido u homologado bajo estándar TIER, con capacidades N+1. La seguridad debe haber sido construida bajo estándar ISO 27002-2013 o similar. Ambos Data Centers deben encontrarse físicamente separados.

Housing: Entregar espacio de rack dedicado para equipamiento de seguridad y redes. Debe contar con circuitos eléctricos independientes y redundantes. En Data Center secundario se permite espacio de rack compartido.

Entorno virtual: Debe considerar un entorno virtual VMWare, cuyas capacidades de hardware deben ser exclusivas, sin oversuscription. El hardware no puede ser superior a 36 meses de antigüedad. Las capacidades de almacenamiento deben considerar discos de alta velocidad o estado sólido. La capacidad en IOPs debe ser propuesto por el proveedor. En el Data Center secundario se permite oversuscription hasta 4:1.

Migración: Migración de servidores físicos y virtuales desde la infraestructura actual debe ser considerada como parte del proyecto.

3.6.2 Redundancia y capacidad de crecimiento

Ambos Data Centers deben contar en todas sus características con redundancia N+1. Se solicita evaluar un crecimiento normal esperado de un 20% en los recursos a consumir. Se solicita evaluar un crecimiento agresivo de un 50% en los recursos a consumir. Planificación de recursos proactivo con estimación de 3 meses en adelante.

3.6.3 Replicación

Entorno virtual debe ser replicado entre ambos Data Centers utilizando tecnologías diseñadas para ello como clúster extendido de VMWare o Veeam y no técnicas manuales como scripting.

3.6.4 Respaldo

El proveedor es responsable por los trabajos de respaldo, los cuales se pueden efectuar en disco o cinta. La política de retención debe ser la siguiente: a) respaldos cada hora, 48 horas. b) respaldos diarios, 5 días y c) respaldos semanales su retención es de 30 días.

Mensualmente se deben efectuar respaldos completos con retención anual. En caso de ocurrir, la falla de la plataforma de respaldo esta no puede ser mayor a 48 horas.

3.6.5 Recuperación ante desastres (DRS)

Ambos Data Centers deben estar interconectados en un entorno LAN extendido, que permita la replicación den entorno virtual, además de proporcionar la ruta para la alta disponibilidad de los servicios. Esta conexión debe ser redundante.

El tiempo de recuperación ante desastre (RTO) requerido es de 4 horas o menor. El punto de recuperación ante desastre (RPO) requerido es de 24 horas o menor. La activación del sistema DRS debe ser automática y debe ser testeada al menos 2 veces al año,

proporcionando evidencia y plan de mejora.

3.6.6 Enlaces de comunicación

Se requiere acceso a Internet redundante en ambos Data Centers, el cual debe contar con el mismo direccionamiento IP, ya sea utilizando protocolos como BGP, o balanceadores de carga.

Interconexión entre Data Centers debe ser de 1Gbps y contar con 5ms de latencia o menor.



14

Se debe permitir acceso a proveedores de red corporativa u opcionalmente, cotizar el acceso WAN. Sin embargo, este punto no se considera como parte del proyecto.

3.6.7 Diseño conceptual

A continuación, se presenta un diseño conceptual del Data Center que puede ser considerado para la evaluación. Se aprecian las características descritas en los puntos anteriores.

Imagen 1. Diseño conceptual de Data Center.

3.7 Comparativa alto nivel y estimación técnica

En base a los requerimientos técnicos se solicitaron estimaciones del proyecto a 3 importantes proveedores del mercado Brasilero, Algar, Embratel y Century Link. Estas propuestas se compararon tomando en cuenta las capacidades ofrecidas y la cobertura por cada uno de los requerimientos. Housing: Capacidad y características del housing de equipamiento en el Data Center. Entorno virtual: Caracteristicas técnicas de los entornos virtuales que se ofrecen en la propuesta. Migración: Experiencia y metodología de migración de datos y servidores actuales. Monitoreo: Características y capacidades del monitoreo del Data Center. Respaldo: Características técnicas de las capacidades de respaldo y recuperación de información. DRP: Tipo y tiempos de recuperación de desastres (RTO/ RPO) Enlaces: Capacidades y características de los enlaces a Internet, interconexión de Data Centers y enlaces corporativos. Replicación: Replicación de datos entre Data Centers Valor agregado: Características específicas entregadas por el proveedor que lo hacen único en comparación a otras alternativas de solución.



15

Sin embargo, la evaluación final se realiza en base a los 3 aspectos más relevantes del proyecto, basados en los requerimientos del negocio:

Precio: Costo total de la solución en USD$, considerando un contrato a 36 meses. Disponibilidad: Disponibilidad de servicios en los Data Centers, cuya medición se realiza en porcentaje de

disponibilidad al año, basados en estándar TIER (Norma TIA-942) [Web-010]. Crecimiento: Capacidad de crecimiento del entorno virtual en escenario de crecimiento normal (20%) y

agresivo (50%) sin afectar la continuidad operativa del negocio.

Para facilitar la comparación se otorga a cada proveedor un valor de 1 a 5, donde 5 es la puntuación más alta por cada aspecto. El color indica además si la propuesta destaca (verde), o no es lo suficientemente adecuada (rojo).

Tabla 6. Comparativa general de proveedores.

PROVIDER GROWTH CAPACITY AVAILABILITY MONTHLY PRICE (36 month contract)

KPI

Algar

High performance Virtual environment in both Data Centers

99,98 USD$ 16,500

5 4 4 13

PROVIDER GROWTH CAPACITY AVAILABILITY PRICE USD KPI

Embratel Very specific growth capacity 99,8 USD$ 60,000

4 2 1 7

PROVIDER GROWTH CAPACITY AVAILABILITY PRICE USD KPI

Century Link

Server/ Storage seems too tight. It is not clear how will be scale

99,98 USD$ 17,000

1 4 4 9

Considerando las características relevantes para el negocio, la comparativa arroja que la propuesta del proveedor Algar se ajusta a las necesidades del proyecto. Se considera en la propuesta las mismas características del entorno virtual requerido en el punto 3.6.1 tanto para el Data center primario, para el entorno virtual del Data Center secundario, entregando un mejor performance que el solicitado en caso de falla del entorno principal. El costo de la solución se acerca bastante al mejor precio otorgado por Century Link, sin embargo, esta propuesta falla en entregar una capacidad de crecimiento adecuada. Finalmente, la propuesta entregada por Embratel es 4 veces más costosa que las demás y la disponibilidad de servicio no es la mejor, teniendo como resultado la solución peor evaluada.

3.8 Costos de la infraestructura local

Si la compañía decide no continuar con el proyecto, de igual forma se deberá incurrir en gastos para soportar el crecimiento y la necesidad de disponibilidad en la infraestructura actual. Se incluyen solo costos tangibles, dejando de lado la evaluación económica de las pérdidas para el negocio que involucrarían fallas en la infraestructura local. La capacidad evaluada alcanza un 99,74% de disponibilidad, lo que significa un servicio TIER 2. Evaluar sobre este nivel implica cambios muy complejos de realizar, por ejemplo, cambios en el edificio corporativo, habilitando, grupos electrógenos y aire acondicionado redundante de precisión.

Los costos evaluados son los siguientes:

Servidores: Costos de renovación de servidores, sus garantías y licenciamiento de entorno virtual. Sala de servidores: Mantenimiento y costos de energía. Con una estimación de crecimiento normal, al año

3 se debe también aumentar el tamaño de la sala de servidores para soportar nuevos racks y servicios de respaldo de energía.



16

DRS: Habilitación de un sitio de recuperación de desastres que puede ser externalizado o habilitado dentro de la misma compañía. Para el caso de estudio se evaluó la habilitación de una segunda sala de servidores, con su costo prorrateado.

Respaldo: Costos de sistema de respaldo, cintas y su almacenaje externo en caso de desastre. Recursos IT: Evaluación del costo de personal IT dedicado al mantenimiento.

Tabla 7. Costos de infraestructura local en USD$.

Year Servers renewal

Servers guarantee

Server room maintenance

VMWare Licenses

Room renovation (growth)

Disaster recovery

Site

Backup tapes

Backups LTO

Tape storage

(External)

IT Resources

(Workload) Total/ year

1 17,246 20,398 11,253 58,096 75,600 2,142 28,238 8,571 17,553 239,097

2 24,478 12,545 139 75,600 257 10,285 21,064 144,368

3 30,722 15,054 13,704 88,942 75,600 3,084 28,238 12,342 25,276 292,962

TOTAL 676,427

3.9 Cloud Privada versus infraestructura local

A continuación, se realiza la comparación de resultados de la evaluación del proveedor Algar versus la infraestructura local. Al comparar costo que implicaría mantener el entorno actual en relación a la propuesta de Cloud privado del proveedor Algar, se obtiene como resultado que, aunque el año 2 es más caro en el Cloud privado, la inversión necesaria en servidores y licenciamiento en el año 1 y 3 encarecen el costo de la solución local. La infraestructura local también implica en el año 3 ampliar las capacidades de la sala de servidores principal, dado que no soportaría el crecimiento en términos de equipamiento, quedando sobre utilizada en este año.

Tabla 8. Comparación de alternativas.

Year Algar

20% growth Local

infrastructure

1 198,000 239,097

2 198,000 144,368

3 198,000 292,962

Total 594,000 676,427

La inversión en Cloud privado al ser constante en el tiempo permite además que la compañía pueda evaluar un presupuesto de forma más eficiente. Es cierto que la inversión en infraestructura podría ser activado mediante Capex, sin embargo, la adquisición y mantenimiento de hardware no es el core del negocio ni debería ser el foco de IT, sino que resolver las necesidades del negocio. Además, esto limita la flexibilidad de por ejemplo, mudarse a un nuevo edificio con facilidad.



17

Gráfico 1. Comparativa de costos

La disponibilidad de servicio en la alternativa de infraestructura local es menor a las capacidades de un Data Center creado y diseñado con este objetivo. Para alcanzar los niveles de servicio de un Data Center en un housing local se debe realizar una fuerte inversión. A pesar de ello, la compañía podría estimar que el nivel de servicio alcanzado en forma local es suficiente para las necesidades del negocio y debe ser planteado, al ser este documento una recomendación. La siguiente tabla muestra la disponibilidad alcanzada por cada alternativa. Mientras que la alternativa de Cloud privada alcanza características de TIER 3, la alternativa local alcanza el TIER 2.

Tabla 9. Comparación de disponibilidad de servicio.

Alternative TIER % Availability % Downtime Downtime/ year

Algar TIER III 99, 982 % 0,02% 1,57 hours

Local infra TIER II 99,74% 0,25% 22,68 hours

4 Guía de buenas prácticas

La experiencia obtenida en el proyecto, se transforma en una guía de buenas prácticas para el desarrollo de proyectos similares.

4.1 Objetivos

El proyecto debe estar definido bajo requerimientos específicos del negocio y debe resolver problemáticas reales y tangibles. Esta claridad le otorga un objetivo claro, que ayuda a tener claridad al momento de definir el alcance, el diseño, ayuda en la toma de decisiones y a resolver conflictos. Por lo tanto, un proyecto de estas características precisa surgir no desde una necesidad del área de TI sino desde la alta gerencia.

4.2 Planificación

Una planificación activa es la clave para el éxito. Es necesario contar con un Jefe de Proyecto experimentado que pueda comprender y dimensionar su complejidad. Este JP debe ser líder, estar dedicado e involucrarse

198 239

198 144

198 293

594

676

-

100

200

300

400

500

600

700

800

Algar20% growth

Localinfrastructure

USD

$ K

3

2

1

Total



18

completamente en el proyecto. Ser capaz de manejar situaciones complejas con diversos proveedores de servicio. Se debe lograr que los KPIs del proyecto sean también los de este rol. Sin embargo no puede estar solo, debe tener un constante acompañamiento de la gerencia y del cliente si se trata de un rol externo. El rol debe ser activo y tener la capacidad y la delegación suficiente para tomar decisiones. En ningún caso el rol puede ser parte del proveedor del servicio.

4.3 Preparación

Entorno. Como paso previo al proyecto, se debe analizar la infraestructura local y realizar acciones preventivas en miras al proyecto. Flexibilizar las redes, eliminando enrutamiento estático, implementando mejores prácticas en los entornos virtuales, actualizando diagramas, instalando actualizaciones, entre otras acciones, ayudan a comprender más profundamente las características y limitaciones de la infraestructura local. Este conocimiento es muy valorable al momento de generar los documentos para el proyecto, en la interacción con los proveedores para definir la solución y en el proceso de migración.

Aplicaciones. Las aplicaciones del negocio obviamente son críticas a la hora de determinar el tipo y las características de la solución. Por lo tanto, un análisis profundo de las aplicaciones a través de un BIA (Business Impact Analysis). Los resultados se deben presentar y validar con el negocio y definir en conjunto el tipo de Cloud que se requiere.

4.4 Diseño

Diseño flexible. Un punto relevante es permitir a la solución la flexibilidad necesaria para que exista independencia de los diferentes elementos que componen, en este caso, del Cloud privado. En la práctica significa separar el diseño en capas e independizar los elementos que lo componen, para que fallas en cierta capa o componente no afecte al resto. Una práctica eficiente para permitir esta flexibilidad es unir ambos Data Centers a través de una LAN extendida. Esto permite a los componentes trabajar en clúster o alta disponibilidad nativa, y que ante una falla de los elementos, el Data Center no traslade todo el flujo de datos hacia un respaldo o DRS, sino solamente del componente o la capa que presenta la falla.

4.5 Migración

Si bien cada paso debe ser planificado y ejecutado de forma prolija, el proceso de migración es crítico para el éxito del proyecto.

La migración debe ser planeada bajo el objetivo principal que no afecte el negocio ni los usuarios. Dada la gran cantidad de datos la migración debe ser precisa, evaluando los servidores desde el punto de

vista de su dependencia funcional y su criticidad para el negocio. Se debe utilizar un servidor de pruebas y determinar el throughput real de la migración. Si existen cuellos

de botella ya sea a nivel de enlaces de comunicación o plataformas virtuales, se puede realizar una ampliación de los recursos temporal mientras dura este gran flujo de datos.

Realizar la migración en forma paulatina, comenzando con los servidores y servicios de menor criticidad, para luego continuar con los que son esenciales para el negocio.

Implementar el diseño final de forma definitiva. Los cambios posteriores a la migración pueden ser muy dolorosos. Es importante que el entorno tenga implementada la capa de red con los protocolos y redundancias previos a la migración, ya que aunque exista un beneficio temporal para disminuir los tiempos de migración, por ejemplo, implementando una fibra oscura entre la oficina a migrar y el Data Center, la complejidad de deshacer estos cambios hacen que el costo- beneficio no sea adecuado.

4.6 Aprendizaje

Una vez finalizado el proyecto, es muy importante detenerse y analizar cuáles fueron los resultados obtenidos y donde el equipo tuvo un gran performance y donde existieron oportunidades de mejora para futuros proyectos. Jamás desde una crítica sino manteniendo el punto de vista del proyecto.



19

5 Conclusiones

En la actualidad las empresas tienen la necesidad de contar con una infraestructura mejorada que permita mantener la continuidad operativa del negocio y soportar los nuevos desafíos tecnológicos. En el caso particular del proyecto del estudio la empresa además tiene la necesidad de crecer, y la infraestructura debe soportar este crecimiento. No sirve para ello cualquier solución, esta debe ser robusta, cumplir los requerimientos establecidos y proveer confianza y respaldo. El análisis de las alternativas de solución muestra que la recomendación al negocio debe ser implementar una solución Cloud privada por sobre la alternativa local. Las restricciones económicas dirán si el proyecto viable. Sin embargo, a priori se muestra que permanecer en la infraestructura actual en el mediano plazo significará una mayor inversión a un mayor riesgo.

5.1 Comprobación de hipótesis

El resultado valida la hipótesis planteada mediante las variables de control del proyecto, ya que el proyecto Cloud es más conveniente que permanecer en la infraestructura local.

El análisis concluye que el costo de mantener la infraestructura local es más alto que la solución de Cloud privada. Esto se debe, entre otros costos, a las inversiones de implementar un sitio de recuperación (DRS) para minimizar el riesgo, y la ampliación de la sala de servidores al año 3 para enfrentar el crecimiento organizacional.

El riesgo de la infraestructura local es más alto que un Cloud, esto debido a que el entorno local no puede garantizar la misma disponibilidad de servicio; para ello se tendrían que realizar inversiones millonarias que harían el proyecto inviable. Además, los tiempos de recuperación ante desastres son mayores por no contar con un entorno replicado.

La capacidad de crecimiento es menor en el entorno local, limitando al negocio a un ambiente que tiene una baja flexibilidad de enfrentar nuevos desafíos, transformándose en una preocupación para el negocio.

En la práctica esto significa recomendar a la alta gerencia la solución de un entorno Cloud sobre uno local. Como trabajo futuro queda perfeccionar el diseño del Data Center de Cloud privado y eventualmente inter conectarlo con Cloud pública, en el cual se prevé en los próximos pueda transformarse en la primera opción al momento de desarrollar un Cloud.

5.2 Conclusiones del proceso de migración

Respecto al proceso de migración, se concluye que una buena práctica es realizar la migración en forma paulatina, en olas, obteniendo aprendizajes y mejora continua en cada una de ellas. Para ello se analizaron los servidores de acuerdo al servicio que entregan, categorizándose en 3 niveles de importancia: normal, importante y crítico. Claramente se comienza el proceso de migración con los servicios contenidos en servidores catalogados con importancia “normal”. Estos servicios no presentan un impacto visible para los usuarios, por ejemplo, servicios de monitoreo. Se elaboró el siguiente procedimiento de migración para la primera ola. Luego, se midieron los tiempos, se realizaron ajustes en las configuraciones y se determinaron mejoras en las condiciones de migración.

Previo a la migración - Revisión y levantamiento servidores a trasladar - Verificar conectividad entre ambiente Cloud privado y ambiente de origen. - Instalación de agentes para respaldo de VM origen - Configuración de políticas de respaldo - Respaldo full de VM origen - Verificación y revisión de respaldos de VM origen - Respaldo incremental de VM origen



20

Traslado - Respaldo incremental final, con servicios y aplicaciones detenidas - Verificación de último respaldo incremental - Reconstrucción VM en infraestructura Cloud - Configuración, dimensionamiento y encendido de servidor - Deshabilitación de red servidor origen, activación nuevo servidor - Validación de funcionamiento del nuevo servidor - Aceptación o rollback del servidor - Conclusiones para siguiente traslado.

En la segunda ola, mencionada como servicios importantes (entre los cuales se incluyen servicios de impresión y Fileservers), se coordinó con los usuarios internos, informando de un período de interrupción de servicio aceptable por el negocio. La migración se comienza la noche del viernes, con el fin de tener tiempo de reacción (corrección o rollback) durante el fin de semana. La experiencia demostró que la práctica de realizar un respaldo incremental, para luego apagar la máquina y realizar un nuevo incremental del delta (que resultó en todos los casos de muy pocos MBytes), produjo que la indisponibilidad de servicios fuese imperceptible. De cada ola se obtienen reportes de los resultados para su análisis. Se analizan los resultados y para la ola de migración de los servicios más críticos, se dividió por servicio y la cantidad de datos a trasladar, tomando 3 fines de semana. Por ejemplo, se migraron todos los servidores de Microsoft Exchange como entorno. No se permitió la migración de elementos fuera de la planificación.



21

6 Referencias

[1] [Web-001] Forbes. (2017). 2017 State Of Cloud Adoption and Security. [Online]. Available: https://www.forbes.com/sites/louiscolumbus/2017/04/23/2017-state-of-cloud-adoption-and-security/

[2] [Web-002] Mundo Marketing. (2018). Amazon invertirá 1.000 millones de dólares en chile. [Online]. Available: https://www.mundomarketing.com/amazon-invertira-1-000-millones-de-dolares-en-chile/

[3] [Web-003] Google Developers Day. (2017). Containers, Kubernetes and Google Cloud. [Online]. Available https://www.youtube.com/watch?v=mhYJ1AX4dG4

[4] [Web-004] Containers V/S Virtual Machines. (Enero 2018). [Online]. Available: http://techgenix.com/vmware-rebound-in-2018/

[5] [Web-005] Juan Maria Fiz. (Nov 2017). Por qué todos apuestan por Kubernetes. https://www.paradigmadigital.com/techbiz/por-que-todos-apuestan-por-kubernetes/

[6] [Web-006] Economía y Negocios. (Mayo 2018). Grupo Gtd se une a Microsoft. [Online]. Available: http://www.economiaynegocios.cl/noticias/noticias.asp?id=473906

[7] [Web-007] Hewlett Packard Enterprise. (2016). Application Migration to [8] On-Premises Cloud. [Online]. Available: https://h20195.www2.hpe.com/V2/getpdf.aspx/4AA6-3932EEW.pdf [9] [Web-008] EMC. (2010). El camino de TI de EMC hacia la nube privada. [Online].

Available: https://chile.emc.com/collateral/software/white-papers/h7298-it-journey-private-cloud-wp.pdf [10] [Web-009] Fundación Chile. (Septiembre 2016). Chile 4.0: Cloud Computing Y El Futuro De La Productividad.

[Online]. Available: http://fch.cl/recurso/corporativo/chile-4-0-cloud-computing-futuro-la-productividad/ [11] [Web-010] Data Center, el estándar TIA- 942. (Febrero 2014). Available: https://www.c3comunicaciones.es/data-

center-el-estandar-tia-942/



22

7 Anexo

7.1 Organización de los capítulos

El trabajo se divide en 6 capítulos

Introducción: Indica el contexto, la problemática, define el problema y la solución planteada. Marco teórico: Información relevante del marco teórico que involucra el proyecto. Desarrollo: Desarrollo del proyecto en sí mismo, en las siguientes etapas:

- Introducción a la empresa - Objetivos del proyecto y estrategia de negocio - Levantamiento de servicios y sistemas actuales y su proyección - Generación de análisis de impacto de los servicios - Análisis de los tipos de Cloud - Análisis de los requerimientos técnicos para la propuesta - Comparativa alto nivel - Costos de la infraestructura local - Cloud privada versus infraestructura local

Guía de buenas prácticas y conclusiones finales - Comprobación de la hipótesis presentada

Conclusiones del trabajo Referencias bibliográficas

Frias Rodrigo Tesina final ultimos comentarios RevisadoDGonzalez · 2019. 1. 9. · 8qlyhuvlgdg...

Documents

Transcript of Frias Rodrigo Tesina final ultimos comentarios RevisadoDGonzalez · 2019. 1. 9. · 8qlyhuvlgdg...