Tesina 2018 Frias-Rodrigo

Universidad Técnica Federico Santa María
Departamento de Informática
Magíster en Tecnologías de la Información
Evaluación de una Migración a Cloud Computing
Rodrigo Frias Toledo
Empresa Pacific Hydro

Isidora Goyenechea 3520, Las Condes, Santiago
rfrias@pacifichydro.cl
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
1
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
2
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
3
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.
4
 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.
5
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.
6
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.
Hosted Shared /
Business Function Description Hosting Type
in Dedicated
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
7
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.
8
Tabla 3. Matriz de impacto de funciones y sistemas.
How long before the

Other considerations when the
RTO (Recovery time objective) When needs to be restore to stop produces sanctions
function must be restored
1 As soon as possible or legal issues
2 24 hours tolerance
Avoid Avoid Provide Provide Support to To To do not To avoid To avoid Avoid a
3 2 to 3 days Summary
financial energy support/ info key the complain fulfill employees harm to damage to
4 4 to 10 days
loss generation to other information business with contracts to leave people the public
5 11 to 29 days
stops departments to allow leadership regulatory image/
6 Up to a month
taking market reputation
decisions
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
9
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
10
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.
11
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:
12
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.
13
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.
14
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.

MONTHLY PRICE
PROVIDER GROWTH CAPACITY AVAILABILITY KPI
(36 month contract)
High performance Virtual
99,98 USD$ 16,500
Algar environment in both Data Centers
5 4 4 13
PROVIDER GROWTH CAPACITY AVAILABILITY PRICE USD KPI
Very specific growth capacity 99,8 USD$ 60,000

Embratel
4 2 1 7
PROVIDER GROWTH CAPACITY AVAILABILITY PRICE USD KPI
Server/ Storage seems too tight. It is
Century 99,98 USD$ 17,000
not clear how will be scale
Link
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.
15
 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$.
Room Disaster Tape IT

Servers Servers Server room VMWare Backup Backups
Year renovation recovery storage Resources Total/ year
renewal guarantee maintenance Licenses tapes LTO
(growth) Site (External) (Workload)
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.
Algar Local
Year
20% growth 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.
16
800
USD$ K
676
700
594
600
293
500 198
3
400 2
300 198 144 1
200 Total
100 198 239
-
Algar Local
20% growth infrastructure
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
17
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.
18
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
19
 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.
20
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/
21
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
22

Tesina 2018 Frias-Rodrigo

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tesina 2018 Frias-Rodrigo

Încărcat de

Drepturi de autor:

Formate disponibile

Universidad Técnica Federico Santa María

Evaluación de una Migración a Cloud Computing

Rodrigo Frias Toledo

Empresa Pacific Hydro

Palabras Clave: Cloud, migración, seguridad, buenas prácticas

Mayor escalabilidad. Agilidad para responder a cambios en la demanda y rapidez en el despliegue de

1.1 Descripción del problema

1.1.2 Incompatibilidad de aplicaciones

1.1.3 Servicios Cloud de calidad

1.1.4 Políticas y leyes

En cuanto a la migración de la infraestructura de una empresa a Cloud, no se trata de un proceso trivial; es un

1.1.6 Ancho de banda, latencia y Jitter

1.2 Propuesta de solución

1.3 Objetivo General

1.4 Objetivos Específicos

Otros objetivos son:

Tabla 1. Variables de la hipótesis.

KPI Variables independientes Variables Dependientes

1.5.1 Estrategia de validación

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

2.1 Estado del arte

2.1.1 Cloud pública

2.1.2 Cloud Containers

Containers (o dockers) [Web-003] es la nueva tendencia de la industria. Se trata de un nuevo modelo de

2.1.3 Plataformas Multi-Cloud

2.2 Proyectos similares

3 Desarrollo del proyecto

3.2 Objetivos del proyecto

3.3 Servicios y sistemas actuales

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

Corp Communication Phone system on Premise Brasil Dedicated Local Client

Financial processes Financial systems Cloud/ premise External Shared Web

Mainteinance Plant mainteinance Cloud External Shared Web

3.4 Análisis de impacto

Se incluye la tabla en una hoja vertical para una mejor comprensión.

Tabla 3. Matriz de impacto de funciones y sistemas.

How long before the

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

Financial processes Fortes 3 5 3 3 3 3

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

Tabla 5. Sistemas críticos hosteados en infraestructura local

3.5 Análisis de los tipos de Cloud

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

Los requerimientos solicitados a los proveedores son los siguientes:

3.6.1 Data Centers

3.6.2 Redundancia y capacidad de crecimiento

3.6.5 Recuperación ante desastres (DRS)

3.6.6 Enlaces de comunicación

3.6.7 Diseño conceptual

Imagen 1. Diseño conceptual de Data Center.

3.7 Comparativa alto nivel y estimación técnica

Tabla 6. Comparativa general de proveedores.

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

3.8 Costos de la infraestructura local

Tabla 7. Costos de infraestructura local en USD$.

Room Disaster Tape IT

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

Tabla 8. Comparación de alternativas.

100 198 239

Gráfico 1. Comparativa de costos

La disponibilidad de servicio en la alternativa de infraestructura local es menor a las capacidades de un Data

Tabla 9. Comparación de disponibilidad de servicio.