-
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
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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.
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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.
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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.
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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.
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Informació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
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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.
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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:
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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.
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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.
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Informació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.
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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.
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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.
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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.
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Informació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/
-
Universidad Técnica Federico Santa María Departamento de
Informática
Magíster en Tecnologías de la Información
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