migración y actualización del servicio aaa y aplicativos

167
MIGRACIÓN Y ACTUALIZACIÓN DEL SERVICIO AAA Y APLICATIVOS DE ADMINISTRACIÓN DE UN CENTRO DE DATOS A OTRO REDUNDANTE ERIKA ANDREA GONZALEZ CAICEDO UNIVERSIDAD AUTONOMA DE OCCIDENTE FACULTAD DE INGENIERÍA DEPARTAMENTO DE AUTOMÁTICA Y ELECTRÓNICA Y TELECOMUNICACIONES PROGRAMA DE INGENIERÍA ELECTRÓNICA SANTIAGO DE CALI 2013

Upload: khangminh22

Post on 11-May-2023

0 views

Category:

Documents


0 download

TRANSCRIPT

MIGRACIÓN Y ACTUALIZACIÓN DEL SERVICIO AAA Y APLICA TIVOS DE ADMINISTRACIÓN DE UN CENTRO DE DATOS A OTRO

REDUNDANTE

ERIKA ANDREA GONZALEZ CAICEDO

UNIVERSIDAD AUTONOMA DE OCCIDENTE FACULTAD DE INGENIERÍA

DEPARTAMENTO DE AUTOMÁTICA Y ELECTRÓNICA Y TELECOMUNICACIONES

PROGRAMA DE INGENIERÍA ELECTRÓNICA SANTIAGO DE CALI

2013

2

MIGRACIÓN Y ACTUALIZACIÓN DEL SERVICIO AAA Y APLICA TIVOS DE ADMINISTRACIÓN DE UN CENTRO DE DATOS A OTRO

REDUNDANTE

ERIKA ANDREA GONZALEZ CAICEDO

Proyecto de Grado para optar al título de Ingeniera Electrónica y Telecomunicaciones.

Director HECTOR JOSÉ GÓMEZ GONZÁLEZ

Ingeniero Electrónico

UNIVERSIDAD AUTONOMA DE OCCIDENTE FACULTAD DE INGENIERÍA

DEPARTAMENTO DE AUTOMÁTICA Y ELECTRÓNICA Y TELECOMUNICACIONES

PROGRAMA DE INGENIERÍA ELECTRÓNICA SANTIAGO DE CALI

2013

3

Nota de aceptación

Aprobado por el comité de grado en cumplimiento de los requisitos exigidos por la Universidad Autónoma de Occidente para optar el título de Ingeniera Electrónica y Telecomunicaciones .

LEONARDO SAAVEDRA ________________________Jurado HELMUT RUBIO ________________________Jurado

Santiago de Cali, 15 de Agosto de 2013.

4

AGRADECIMIENTOS

Agradezco a mis padres y a mis hermanos, porque gracias a su gran esfuerzo, estoy a punto de terminar mis estudios profesionales; gracias por apoyarme siempre, por enseñarme a creer en mí y en mis metas. Sin ellos nada de esto hubiera sido posible. Gracias a la Universidad Autónoma de Occidente, por formarme no solo como profesional, si no, como una persona comprometida a trabajar por un mejor futuro para Colombia. Al Ingeniero Héctor José Gómez, por guiarme y ayudarme en el desarrollo de este proyecto. Al Ingeniero David Blandón y Carlos Araque por abrirme las puertas de su empresa y brindarme la oportunidad de realizar este proyecto. Al equipo de trabajo, por estar siempre dispuestos a responder todas mis inquietudes. Por último, agradezco a mis compañeros y a mis amigos por estar siempre conmigo en todo este proceso dándome su voto de confianza en mis capacidades para alcanzar esta meta.

5

CONTENIDO

GLOSARIO 12

RESUMEN 16

PALABRAS CLAVES 16

INTRODUCCIÓN 17

1. PROBLEMA DE INVESTIGACIÓN 19

1.1. PLANTEAMIENTO DEL PROBLEMA 19 1.2. FORMULACIÓN DEL PROBLEMA 19

2. JUSTIFICACIÓN 20

3. OBJETIVOS 21 3.1. OBJETIVO GENERAL 21 3.2. OBJETIVOS ESPECIFICOS 21

4. META 22

5. MARCO REFENCIAL 23 5.1. MARCO TEÓRICO 23 5.1.1. Centro de datos o data centers 23 5.1.2. Redundancia 32 5.1.3. Virtualización 32 5.1.4. Servicios 36 5.1.5. Equipos de almacenamiento 38

6. METODOLOGIA 42

7. ACTUALIZACION DE LAS POLITICAS DEL AAA 44 7.1. SERVICIO AAA (AUTENTICACION, AUTORIZACION Y ACREDITACION) 44 7.2. PROCEDIMIENTO DE EJECUCION DEL AAA 47

8. ACTUALIZACION EN LA VIRTUALIZACION DE GESTION AD SL Y TICKET. 53

6

8.1. PROCEDIMIENTO DE EJECUCION DE LA APLICACION GESTION ADSL O SIGT 58 8.2. PROCEDIMIENTO DE EJECUCION DE LA APLICACION TICKET 62

9. REINSTALACIÓN DE LOS SERVICIOS. 65

10. ARQUITECTURA DE RED DE LOS CENTRO DE DATOS DE EMCAL I 71 10.1. TOPOLOGIA FISICA 72 10.2. VLAN 73 10.3. SPANNING TREE PROTOCOL (STP) 75

11. RESULTADOS 80 11.1. RESULTADOS AAA 80 11.2. RESULTADOS APLICATIVO TICKET 81 11.3. RESULTADOS APLICATIVO GESTION ADSL 83 11.4. PRUEBAS DE SINCRONIZACION DE DISCOS DE LOS CENTROS DE DATOS 85

12. PROCEDIMIENTOS DE OPERACIÓN Y MANTENIMIENTO 87

13. CONCLUSIONES 90

BIBLIOGRAFÍA 92

7

LISTA DE FIGURAS

Figura 1. Módulo Tier 1 26

Figura 2. Módulo Tier 2 27

Figura 3. Módulo Tier 3 28

Figura 4. Módulo Tier 4 30

Figura 5. Esquema de Redundancia de Emcali Telecomu nicaciones 32

Figura 6. Virtualización de Espectro 34

Figura 7. Chasis SunBlades 6000 39

Figura 8. Sparc T6340 39

Figura 9. SAN 40

Figura 10. Storage 7410 40

Figura 11. Arrays 4400 41

Figura 12. Creación del archivo de la Base de Datos 47

Figura 13. Subida del Servicio LDAP. 48

Figura 14. Finalización de la Subida de la Base de Datos 48

Figura 15. Datos Técnicos de la Subida de la Base d e Datos del AAA 49

Figura 16. Habilitar y Deshabilitar el Servicio par a la Configuración de la

Réplica del LDAP 49

Figura 17. Prueba de Edición en el Servidor Maestro del LDAP 50

Figura 18. Replicación de los Datos del Servidor M aestro y Servidor

Esclavo 51

Figura 19. Cambio de IP's 51

8

Figura 20. Cambio de IP en el BRAS 52

Figura 21. Ubicación de los Aplicativos en el Siste ma 53

Figura 22. Proceso de creación de un LDOM 54

Figura 23. Proceso creación de una ZONA 55

Figura 24. Proceso para Iniciar un LDOM 56

Figura 25. Proceso para Migrar una ZONA 56

Figura 26. Proceso de Backup de la Base de Datos 58

Figura 27. Backup de la Base de Datos de Gestión AD LS 59

Figura 28. Movimiento de Información a las ZONAS 60

Figura 29.Interfaz de Usuario de GESTION ADSL 61

Figura 30.Proceso de Backup de los Datos 62

Figura 31. Movimiento de Información a las ZONAS 63

Figura 32. Interfaz de Usuario de Ticket 64

Figura 33. Arquitectura General 67

Figura 34. Centro de Datos San Fernando y Limonar 7 2

Figura 35. Diagrama de enlaces de las VLAN's. 74

Figura 36. Spanning Tree de la VLAN 113 en la insta ncia 10 78

Figura 37. Spanning Tree de la VLAN 116 en la insta ncia 11 79

Figura 38. Arranque/inicio de LDOMs en Solaris 94

Figura 39. Detener LDOMs en Solaris 95

Figura 40. Backup de LDOM 95

Figura 41. Arranque de Zonas en Solaris 96

Figura 42. Detener una Zona en Solaris 96

9

Figura 43. Migración de Zonas en Solaris 97

Figura 44. Creación Zonas Solaris 98

Figura 45. Centro de datos de Emcali Telecomunicaci ones 99

Figura 46. Conexiones Físicas del Centro de datos d e San Fernando 100

Figura 47. Conexiones Físicas del Centro de Datos d e Limonar 101

Figura 48. VLAN’s de los Centros de Datos de Emcali

Telecomunicaciones 103

Figura 49. Spanning Tree de la Van 113 del Storage 104

Figura 50. Spanning Tree de la Van 113 del Storage 105

10

LISTA DE CUADROS

Cuadro 1.Infraestructura Soporte de un Data Center 24

Cuadro 2. Características para alineamiento Tier II I 30

Cuadro 3. Relación de Disponibilidad vs Tiempo Fuer a Anual 31

Cuadro 4. Distribución de LDOM's y ZONAS SOLARIS 6 8

Cuadro 5.Tipo de Trafico de VLAN's 77

Cuadro 6. Atributos en la Carga de las Páginas de P ruebas entre los

Aplicativos de Pruebas y de Producción 82

Cuadro 7. Diferencia de Atributos en la Carga de la s Páginas de

Pruebas 82

Cuadro 8. Atributos en la Carga de las Páginas de P ruebas entre Testing

y Producción 84

Cuadro 9. Diferencia de Atributos en la Carga de la s Páginas de Pruebas

84

Cuadro 10. Pruebas de sincronización de discos de l os centro de datos

de San Fernando 85

Cuadro 11. Catálogo de Procesos Implementados en lo s Centros de

Datos de Emcali 89

Cuadro 122. Índex de VLAN's 102

11

ANEXOS

Anexo A. PROCESOS DE CREACION DE LDOMS Y ZONAS SOLA RIS 93

Anexo B. DIAGRAMAS DE LOS CENTROS DE DATOS DE EMCAL I-

TELECOMUNICACIONES 99

Anexo C. PROTOCOLO DE PRUEBAS DE EMCALI-

TELECOMUNICACIONES 106

Anexo D. PROCEDIMIENTOS DE OPERACIÓN Y MANTENIMIEN TO 111

12

GLOSARIO AAA (Authentication, Authorization, Accounting): establece los pasos para realizar la validación de datos de los usuarios en el sistema de control del servicio de internet. BACKUP: copia de seguridad total o parcial de la información importante de discos duros, base de datos u otro medio de almacenamiento, esta copia debe ser guardada en otro sistema masivo de almacenamiento para ser usada en caso de pérdida de la copia original. BLADE: chasis de almacenamiento físico de tarjeras o slot de un centro de datos. BRAS (BroadbandRemote Access Server): servidor de Acceso Remoto de Banda Ancha. CRAC: unidades de almacenamiento de aires acondicionados para enfriar servidores de centros de datos. CHILLER: es una unidad enfriadora de líquidos, capaz de enfriar el ambiente con solo usar la misma operación de los aires acondicionados. DIRECCION IP: es una etiqueta numérica que identifica de manera lógica a una interfaz de un dispositivo dentro de una red. DSLAM (Digital Subscriber Line Access Multiplexer ): multiplexor de Línea de Acceso del Abonado. HOSTING (File Storage): residencia de archivos para uno o más sitios web de los grandes clientes con rápida conexión a internet. HUB: es un dispositivo que centraliza el cableado de una red y permite ampliarla, recibe una señal y la repite por todos los puertos conectados.

13

IEEE 802.1Q: este protocolo se encarga del etiquetado de las tramas que se asocia inmediatamente con la información de la VLAN: IMAP (Internet Massage Access Protocol): es el protocolo de red para acceso a mensajes electrónicos almacenados en un servidor. JMETER: es una herramienta de escritorio para cargar el comportamiento de pruebas funcionales y de rendimiento de los recursos aplicados. LDAP (Lightweight Directory Access Protocol): es un protocolo a nivel de aplicación, permite el acceso a un servicio de directorio distribuido para buscar información en un entorno de red. LDOM (Logical Domains): dominios lógicos para almacenar máquinas virtuales. LUN (Logical Unit Number): es el número de unidad lógica en un sistema de almacenamiento, se usa para identificar discos duros externos, conectados a un computador. MULTICAST: es el envío de la información en una red a múltiples destinos de forma simultánea. Se configura una serie de parámetros de acuerdo al tipo de tráfico de datos que se necesite. NAS (Network Attached Storage): es una tecnología de almacenamiento dedicada a compartir la capacidad de almacenamiento de un computador con varios computadores personales o servidores a través de una red. NTP (Network Time Protocol): es un protocolo de Internet que se configura para sincronizar los relojes de los sistemas informáticos a través del ruteo de paquetes en redes. PDU (Power Distribution Unit): es un dispositivo con múltiples salidas para distribuir energía a los bastidores y equipos dentro de un centro de datos.

14

PPPoE (Point to Point Protocol over Ethernet): Punto a Punto sobre Ethernet. RACK: Es un soporte metálico especial para alojar equipos electrónicos, informáticos y de comunicaciones. SAN (Storage Area Network): Es un área de red almacenamiento que proporciona acceso a los datos de una plataforma consolidada. SCSI (Small Computers System Interface): la interfaz de sistemas para pequeñas computadoras es una interfaz estándar para la transferencia de datos entre distintos dispositivos entre diferentes computadoras. SLOT: tarjetas para instalar en un blade para implementar diversos sistemas operativos. STP (Spanning Tree Protocol): conocido como árbol abarcador, evita la aparición de blucles lógicos para que haya un solo camino entre dos nodos. SYSLOG (Standard for Computer Data Logging): es un estándar para el envío de mensajes de registro en una red informática IP. TIA: Asociación de Industrias de Telecomunicaciones en los Estados Unidos, entidad que proporciona los estándares de calidad para los centros de datos. TICKET (Damage Report): Aplicativo que permite tener en una forma ordenada, los reclamos que se reciben en los servicios de telecomunicaciones de Emcali del producto de Banda Ancha. UAM (Unidad de Acceso Multiservicios): permite el acceso a la Red Multiservicios de Emcali Telecomunicaciones a través de puertos configurados en dispositivos ubicados en puntos estratégicos de la ciudad de Cali. VLAN (Virtual Local Area Network): es un método para crear redes lógicas independientes dentro de una misma red.

15

VTP (VLAN Trunking Protocol): permite una gestión centralizada de todas las VLAN’s. XDSL (Digital Subscriber Line): línea de suscripción digital usado para referirse de forma global a todas las tecnologías que proveen una conexión digital sobre la línea de abonado de la red telefónica básica o conmutada. ZONAS SOLARIS: son distribuciones que se usan para virtualizar servicios de los sistemas operativos y mejorar rendimiento y seguridad en una plataforma.

16

RESUMEN El área de Telecomunicaciones de las Empresas Municipales de Cali - EMCALI EICE E.S.P, tienen los servicios: AAA, Gestión ADSL y Ticket. El AAA consiste en validar la información de cada uno de los usuarios afiliados al producto de Internet Banda Ancha. Gestión ADSL hace el seguimiento al proceso de instalación cuando se tramita una venta. Ticket es el aplicativo que reporta los daños que notifican los clientes cuando falla el producto después de ser instalado. Estos servicios están almacenados en el centro de datos en la Sede Limonar. Al adquirir el centro de datos construido en la Sede de San Fernando, los servicios fueron actualizados y migrados. Este proceso se hizo porque no había una plataforma redundante, ni un plan de contingencia o Backup por si falla el centro de datos de Limonar. La actualización consistió en virtualizar los dos centros de datos y las políticas de autorización del AAA. La migración se implementó por medio de la configuración de las tarjetas o slots, creación de máquinas virtuales y niveles de virtualización en la plataforma. Como resultado, después de hacer las configuraciones en las dos plataformas, los servicios quedaron sincronizados en los dos centros de datos. Se disminuyó la perdida de información con la redundancia implementada y se cumplió con el objetivo de tener un plan de contingencia o Backup para servicios. Esto hace que sea un sistema confiable y de buena calidad para evitar la pérdida de clientes.

PALABRAS CLAVES Actualizar, migrar, servicios, centros de datos, blade, ldom, zonas, procesos, virutalizar.

17

INTRODUCCIÓN En la actualidad la principal estrategia de las empresas de telecomunicaciones a nivel mundial es la virtualización de sus centros de datos. En ellos son almacenados todos los servicios proporcionados a los clientes. Estos son creados con el objetivo de disminuir los riesgos de pérdida de la información, aumentar la calidad de los mismos, optimizar la vida útil de las máquinas y generar mayor eficiencia y confiabilidad de los productos. En el área de Telecomunicaciones de las Empresas Municipales de Cali - EMCALI EICE E.S.P., se ha interesado en contribuir con el desarrollo y bienestar de los clientes, para prestar los servicios públicos esenciales y complementarios con una alta calidad y rentabilidad económica. Lo anterior apunta a la implementación de centros de datos confiables y estables. Desde el año 2006, el área de Telecomunicaciones de EMCALI tiene en la sede de Limonar el centro de datos adquirido. En el que almacenan el producto de Internet Banda Ancha con los catorce servicios complementarios para su correcto funcionamiento. En el análisis de riesgo de la empresa, se identificó que no se tiene estructurado un plan de contingencia, esto afecta la continuidad de los servicios cuando falla el centro de datos en la sede de Limonar. De acuerdo con lo anterior, se adquirieron los equipos correspondientes a un centro de datos alterno, para ser instalados en la sede de San Fernando. Con el objetivo de activar el plan de contingencia que fue recomendado para contar con el mejor soporte e infraestructura donde se puedan almacenar a los nuevos clientes. Los servicios o los aplicativos de administración, al estar residentes en el centro de datos de Limonar, corren el riesgo de sufrir alguna interrupción. Al presentarse esto se genera perdida en la información, porque no hay un plan de contingencia o Backup para ser recuperada. Esto crea desconfianza en la calidad del servicio y provoca el retiro de los clientes hacia las empresas competidoras.

18

Este proyecto se orientó a migrar y actualizar los aplicativos de administración que tiene la empresa, de un centro de datos a otro redundante. Con ésta implementación se realizaron cambios y reajustes de los servicios, se mejoró la integración de las aplicaciones, la autenticación de los usuarios en el producto de Internet Banda Ancha, los parámetros de acceso al puerto de conexión del producto y la eficiencia en tiempos de las aplicaciones. Por otro lado, se generaron los procedimientos y documentación de los procesos que se implementaron en la nueva plataforma. Donde se detallan las características técnicas y la descripción de cada paso que se debe realizar en la creación de las máquinas virtuales en los centro de datos. Se crearon instructivos con los temas relacionados, que cumplen con las políticas de calidad asignadas por la empresa. Con el propósito que sirvan de guía y soporte en el momento que falle alguno de los dos centros de datos que tiene EMCALI y se entregaron al Área de Operación y Mantenimiento para que sean administrados.

19

1. PROBLEMA DE INVESTIGACIÓN 1.1. PLANTEAMIENTO DEL PROBLEMA En EMCALI EICE E.S.P., se detectaron necesidades específicas en el centro de datos de la sede de Limonar, ya que cuenta con un solo repositorio de información generando riesgos de interrupción de los servicios si este llegase a fallar. Actualmente el área de Telecomunicaciones de Emcali, tienen los servicios: AAA (autorización, autenticación y acreditación), Gestión ADSL y Ticket. El AAA consiste en validar la información de cada uno de los usuarios afiliados al producto de internet, Gestión ADSL es el servicio encargado de hacer seguimiento al proceso de instalación del producto y Ticket es el aplicativo en el cual se reportan los daños que los clientes notifican cuando falla el servicio de Internet Banda Ancha. Estos servicios están albergados en el centro de datos de Limonar con el riesgo que sufran alguna interrupción, generando perdida de la información porque no hay un plan de contingencia o backup para recuperarla, creando dudas en la confiabilidad y la calidad del servicio provocando el retiro de los clientes. Por otro lado se presentan falencias en la integración de las aplicaciones, teniendo poca información de los usuarios cuando se autentican en el producto de internet banda ancha, sin tener garantías para que la conexión asigne los parámetros necesarios en el acceso a internet, posición geográfica y tener estadísticas en tiempo real. 1.2. FORMULACIÓN DEL PROBLEMA Ante esta situación se plantea el siguiente problema a resolver, ¿Cómo se pueden migrar y actualizar los servicios para garantizar disponibilidad y continuidad en los dos centros de datos de Emcali Telecomunicaciones?

20

2. JUSTIFICACIÓN El área de Telecomunicaciones de EMCALI EICE E.S.P., como empresa prestadora de servicios, se preocupa por brindar los mejores productos, por tal razón busca estar a la vanguardia de la tecnología en el área de virtualización, confiabilidad y robustez de los procesos, llevando a cabo actualizaciones y optimizaciones para mejorar el desempeño de los servicios. De acuerdo a lo anterior, al adquirir el centro de datos redundante se podrá tener un plan estructurado de contingencia, obtener una alta disponibilidad de los servicios, mejorar el desempeño de las aplicaciones y registrar información clave de los usuarios, para optimizar las unidades de negocio. En este contexto, se migrarán y actualizarán los servicios AAA, Gestión ADSL y Ticket, que están albergados en el centro de datos principal de la sede Limonar, hacia otro centro de datos ubicado en la sede San Fernando de forma redundante, sincronizados y virtualizados. Con el fin de garantizar el continuo funcionamiento de internet banda ancha y la calidad del servicio en la plataforma, se ha adquirido otro dentro de datos para favorecer a los clientes con un servicio rápido, confiable y de alta calidad. En esta dirección Emcali pretende tener clientes satisfechos y evitar la deserción de los mismos.

21

3. OBJETIVOS

3.1. OBJETIVO GENERAL Migrar y actualizar los servicios AAA, Gestión ADSL y Ticket en los dos centros de datos de EMCALI Telecomunicaciones distribuidos geográficamente, para proporcionar alta disponibilidad en el producto de Internet Banda Ancha.

3.2. OBJETIVOS ESPECIFICOS • Actualizar las políticas de autenticación y autorización para garantizar el

proceso de calidad en la conexión para asignar los parámetros de acceso a internet.

• Actualizar el aplicativo Ticket y Gestión ADSL, de virtualización básica

(V0) al estado final en virtualización nivel 2 (V2). • Migrar y Sincronizar las políticas de los servicios AAA, Gestión ADSL Y

Ticket en el centro de datos de la sede de San Fernando para el funcionamiento de forma redundante.

• Documentar la arquitectura final de las topologías físicas y lógicas, basados en el modelo TCP/IP.

• Elaborar los procesos de operación y mantenimiento de la nueva plataforma, de acuerdo a las políticas de calidad del centro de datos en la sede San Fernando.

22

4. META Actualizar los servicios AAA, Gestión ADSL y TICKET, que tiene el área de Telecomunicaciones de las Empresas Municipales de Cali - EMCALI EICE E.S.P, en los centro de datos de Limonar y San Fernando, para lograr la redundancia y sincronización de los datos en ambas plataformas, con el fin de garantizar buena calidad del producto.

23

5. MARCO REFENCIAL 5.1. MARCO TEÓRICO Para este proyecto se definen los siguientes conceptos, donde hay un análisis y diagnóstico del estado de la información que se planteó para desarrollarlo. • Centro de datos o data center. • Redundancia. • Virtualización. • Servicios. • Equipos de almacenamiento.

5.1.1 Centro de datos o data centers. Un data center o un centro de datos, comprende las dependencias y los sistemas asociados gracias a los cuales. • Los datos son almacenados, tratados y distribuidos al personal o

procesos autorizados para consultarlos y/o modificarlos. • Los servidores en los que se albergan estos datos se mantienen en un

entorno de buen funcionamiento. Los primeros centros de datos se diseñaron con las arquitecturas clásicas de las topologías de red, en la que los equipos se podían apilar en mesas, armarios o racks. La necesidad de fácil gestión y de optimización del espacio, ha hecho que se evolucione hacia sistemas basados en equipos cuyas dimensiones permiten aprovechar al máximo el volumen disponible en los equipos y encaminarse hacia la virtualización. Los centros de datos iniciales no estaban diseñados para proporcionar facilidades de red avanzadas, ni con los requerimientos mínimos de ancho de banda y velocidad de las arquitecturas actuales. La rápida evolución de Internet y la necesidad de estar conectados en todo momento han obligado a las empresas a requerir un alto nivel de fiabilidad y

24

seguridad, de tal forma que se proteja la información corporativa y esté disponible sin interrupciones o degradación del acceso, con el objetivo de no poner en peligro los negocios. Estos son algunos de los requisitos para el funcionamiento de un centro de datos: • Asegurar disponibilidad de conexión y servicio 7/24. • Tener protección contra incendios y otras catástrofes naturales. • Control de temperatura y humedad. • Sistema Inteligente para el acceso a los equipos. • Debe tener un sistema ininterrumpido para garantizar que no se afecten

los servicios. Otros requerimientos más detallados se encuentran en los estándares mundiales, que van acorde con el tamaño del data center. El estándar principal es el TIA 942, que fue publicado por la Telecommunication Industry Association en Abril del 2005. Se originó con la intención de unificar los criterios en el diseño en las áreas de tecnología. Basado en especificaciones para comunicaciones y cableado estructurado. Establece cuatro niveles o tiers, en función de la redundancia para alcanzar los niveles de disponibilidad de hasta el 99.995%. Divide la infraestructura en cuatro subsistemas: • Telecomunicaciones. • Arquitectura. • Sistema eléctrico. • Sistema mecánico. Dentro de cada subsistema, el estándar desarrolla una serie de ítems, ver cuadro 1. Cuadro 1.Infraestructura Soporte de un Data Center Telecomunicaciones Arquitectura S. Eléctrico S. Mecánico

Cableado de Racks Selección de sitio

Cantidad de accesos

Sistemas de climatización

25

Accesos redundantes Tipo de construcción

Puntos únicos de falla Presión positiva

Cuarto de entrada Ignifuga* Cargas críticas Cañerías y drenajes

Backbone Barrera de vapor Topologías de UPS

CRAC's y condensadores

Elementos activos Áreas de oficinas Puesta a tierra Detección de incendios redundantes

Patchpanels Salas de UPS y baterías Baterías

Extinción por agente limpio

Patchcords Sala de generador

Monitoreo Detención por aspiración

Documentación Control de acceso

Generadores Detención de líquidos

*Protección contra el fuego. Fuente: EL ESTANDAR TIA 942. Revista Ventas de Seguridad. Metacom. Agosto 2007. Al tener en orden estos subsistemas implementados, las empresas con infraestructuras de centros de datos, desean tener alta disponibilidad. Lo cierto es que para aumentar la redundancia y los niveles de confiabilidad, los punto únicos de falla deben ser eliminados en el data center como en la infraestructura que le da el soporte. Los tiers que plantea el estándar, corresponden a cuatro niveles de disponibilidad. La relación es que a mayor número de tier mejor calidad en el servicio, lo que corresponde que tiene mayores costos constructivos1 . A continuación se explican los niveles de tiers que plantea el estándar. • Tier I: Centro de Datos Básico. Un centro de datos tier I, puede ser susceptible a interrupciones planeadas o no planeadas. Los sistemas de aire acondicionado y la distribución de energía, pueden o no contar con un piso falso, UPS o generador eléctrico. Si

1 MONGE GOMEZ, José Miguel. Estándares sobre Diseño y Funcionamiento de Data Center. IT Ingenieros y Asesores. Grupo Electrónica. Mayo 2008. 47 Pág.

26

los posee podrían no tener redundancia y existir varios puntos únicos de falla. La infraestructura del centro de datos debe estar fuera de servicio al menos una vez al año por razones de mantenimiento. En situaciones de urgencia pueden generar paradas más frecuentes, errores de operación o fallas en los componentes en la infraestructura que causan la detención del centro de datos. La tasa de disponibilidad máxima del centro de datos es 99.671% que se debe al tiempo de parada anual en horas, en este Tier es de 28.82 horas. Ver figura 1. Figura 1. Módulo Tier 1

Fuente: ESTANDAR TIER UPTIME INSTITUD. Datacenter Consultores. Auditoria y certificación. 2007. • Tier II: Componentes Redundantes Los centros de datos con componentes redundantes son ligeramente menos susceptibles a interrupciones, tanto planeadas como las no planeadas. Estos

27

centros de datos tienen un piso falso, UPS y generadores eléctricos, pero están conectados a una sola línea de distribución eléctrica. Su diseño es N+1, lo que significa que existe al menos un duplicado de cada componente de la infraestructura. La carga máxima de los sistemas en situaciones críticas es del 100%. El mantenimiento en la línea de distribución eléctrica o en otros componentes de la infraestructura puede causar una interrupción del procesamiento. La tasa de disponibilidad máxima del centro de datos es 99.749% que se debe al tiempo de parada anual en horas, en este Tier es de 22.68 horas. Ver figura 2. Figura 2. Módulo Tier 2

Fuente: ESTANDAR TIER UPTIME INSTITUD. Datacenter Consultores. Auditoria y certificación. 2007. • Tier III: Mantenimiento Concurrente.

28

La capacidad de este tipo de centro de datos, permite realizar cualquier actividad planeada sobre cualquier componente de la infraestructura sin interrupciones en la operación. Las actividades planeadas incluyen mantenimiento preventivo y programado, reparaciones o remplazo de componentes, agregar o eliminar elementos y realizar pruebas de componentes o sistemas operativos. Debe existir suficiente capacidad y doble línea de distribución de los componentes, de forma tal que sea posible realizar mantenimiento o pruebas en una línea, mientras que la otra línea atiende la totalidad de la carga. En este tier, actividades no planeadas como errores de operación o fallas espontáneas en la infraestructura pueden causar una interrupción del centro de datos. La carga máxima de los sistemas en situaciones críticas es de 90%. Muchos centros de datos tier III son diseñados para poder actualizarse a tier IV, siempre y cuando los requerimientos del negocio justifiquen el costo. La tasa de disponibilidad máxima del centro de datos es 99.982% que se debe al tiempo de parada anual en horas, en este Tier es de 1.57 horas. Ver figura 3. Figura 3. Módulo Tier 3

29

Fuente: ESTANDAR TIER UPTIME INSTITUD. Datacenter Consultores. Auditoria y certificación. 2007. • Tier IV: Tolerante a Fallas. Este centro de datos tiene la capacidad para realizar cualquier actividad planeada sin interrupciones en las cargas críticas, pero además la tolerancia a fallas le permite a la infraestructura continuar operando ante un evento crítico no planeado. Esto requiere dos líneas de distribución simultáneamente activas, en una configuración “sistema + sistema”; eléctricamente esto significa dos sistemas de UPS independientes, cada sistema con un nivel de redundancia N+1. La carga máxima de los sistemas en situaciones críticas es de 90%.

30

La tasa de disponibilidad máxima del centro de datos es 99.995% que se debe al tiempo de parada anual en horas, en este Tier es de 52.56 minutos. Ver figura 42. Figura 4. Módulo Tier 4

Fuente: ESTANDAR TIER UPTIME INSTITUD. Datacenter Consultores. Auditoria y certificación. 2007. El centro de datos de San Fernando quedó con alineamiento Tier II. En el cuadro 2 se muestran las características que cumplió el centro de datos en el momento de hacer todo el procedimiento de la certificación. Cuadro 2. Características para alineamiento Tier II I

Características. Tier III.

Tipo de edificación No combustible (Concreto o albañearía)

Manutención del equipamiento En el mismo turno y sitio 24/7, Jefe de turno y turno por operadores con rotación

2 FERNANDEZ, Víctor. DATA CENTER ACTIVO - ACTIVO CON VIRTUALIZACION. Blog: Portal en castellano para entusiastas de la gestión de servicios y proyectos basados en tecnologías de virtualización, sistemas, almacenamientos, backup y cloudcomputing

31

Sistema de transferencia de carga critica

Transferencia automática a UPS y generador

Cantidad de watts inicial por m2

430 - 645 W/m2

Sistema de monitoreo UPS Si, requerido

Aire acondicionado sin interrupción

Suficiente para mantener área critica durante la falla, configuración N+1

Control de humidificación Si, requerido, configuración N+1

Resistencia al fuego 1 hora de resistencia en muros interiores y exteriores

Construcción del techo Techo falso, cubierta no combustible

Ninguna ventana exterior en el perímetro del centro de datos

Si, requerido

Punto de falla únicos Algunos + errores humanos Down time por año 1,57 horas Disponibilidad del data center 99,98% Redundancia N+1

Fuente : Tier Classification DefinesSiteInfraestructure. UptimeInstitute, INC. Por otro lado, en el cuadro 3 se muestra la relación que hay entre la tasa de disponibilidad y el tiempo de paradas anuales de los servicios albergados en un centro de datos. Cuadro 3. Relación de Disponibilidad vs Tiempo Fuer a Anual

Tier % de tasa Disponibilidad

% de Parada

Tiempo de la parada anual

Tier I 99,671 0,329 28,82 horas Tier II 99,741 0,251 22,68 horas Tier III 99,982 0,018 1,57 horas Tier IV 99,995 0,005 52,56 minutos

Fuente: White paper: Tier Classification Defines Site Infrastructure Performance. UptimeInstitute, INC.

32

5.1.2. Redundancia. La redundancia es empleada para detectar errores y ejecutar la recuperación hardware o software. La información viaja a través de la red para que se genere una repetición en los datos para el almacenamiento de información y contar con un sistema que no genere detención en una plataforma. Una de las propiedades se refiere al almacenamiento de datos informáticos, que hacen los discos, que proporciona tolerancia a fallos y recuperación de datos. En la figura 5 se observa el esquema de redundancia que quedó aplicado para los centros de datos de Emcali Telecomunicaciones. Figura 5. Esquema de Redundancia de Emcali Telecomu nicaciones

REDUNDANCIA DE DATOS EN LA PLATAFORMA DE EMCALI

Centro de Datos San Fernando Centro de Datos de Limonar

RMS

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012

5.1.3. Virtualización. La virtualización era una tecnología al alcance de las grandes compañías, ahora cualquier empresa tiene estos beneficios. Al ser más asequible a esta tecnología se puede poner a disposición más opciones en los sistemas operativos, reducir costos y tener mayor control sobre la estructura implementada. La tecnología ofrece la posibilidad de disponer de varios servidores instalados en una maquina física con características distintas. Es posible hacer que los recursos de un computador, en este caso un servidor, puedan ser compartidos por una o más máquinas virtuales que se comportan a su vez como servidores reales.

33

A las máquinas virtuales se asigna recursos de hardware diseñado con distintas configuraciones y características independientes. Estos recursos pueden ser compartidos o se pueden bloquear de forma que cada máquina virtual tenga su propia memoria RAM, CPU, disco duro, recursos de red, sistema operativo y aplicaciones3. Las ventajas de los servidores virtualizados frente a servidores físicos son las siguientes: • Ahorro de costos: Poder adquirir un solo servidor más potente y no

invertir en más servidores, sino crear en el gestor de máquinas virtuales. Esto permite ahorrar espacio, mantenimiento y en personal capacitado.

• Crecimiento más flexible: Instalar un servidor virtual es más sencillo y rápido frente a un servidor físico.

• Administración simplificada: Desde la consola del gestor de máquinas virtuales se puede aumentar o reducir los recursos para una determinada máquina, reiniciar, instalar parches o borrar en caso de problemas.

• Disposición de aplicaciones antiguas : Se tiene la posibilidad de conservar aplicaciones que funcionan en sistemas antiguos.

• Centralización de tareas de mantenimiento: Realizar copias de seguridad de todas las máquinas, programar actualizaciones y otras actividades desde el gestor de máquinas virtuales.

• Disminuye tiempos de parada: Solucionar problemas o realizar copias de seguridad en menor tiempo.

• Balanceo de recursos: Asignar un grupo de servidores físicos para que proporcionen recursos a las máquinas virtuales, con más memoria, recursos de la CPU, almacenamiento o ancho de banda.

La desventaja de los servidores virtualizados frente a los servidores físicos es que presenta conflictos con el licenciamiento como en casos de actualizaciones por ser en muchos casos es una plataforma abierta y que aplican los fabricantes de software. El software de virtualización representa un desafío para los tipos de licencia por usuario existente, es probable que cambien las reglas con respecto al. Claro está que la instalación y administración requiere de personal calificado en Tecnologías de la Información.

3 SU, Holglin. Converting Linux and Windows Physical and Virtual Machines to Oracle VM Virtual Machines. Oracle Corporation. Indiana USA. 2008. 516 Pág.

34

Por otro lado la virtualización es presentada en términos de dos características: Flexibilidad y Aislamiento. El aislamiento que se refiere a los niveles de virtualización, este es mayor en los sistemas virtuales y la flexibilidad es menor en la asignación de recursos4. Se puede crear un espectro de flexibilidad de los recursos en comparación con el aislamiento en la carga de trabajo que se muestra a continuación. Figura 6. Virtualización de Espectro

VIRTUALIZACION

VIRTUALIZACION SOMAQUINA VIRTUALPARTICIONES

PARTICION

Sistema Operativo

PARTICION

Sistema Operativo

INTERCONEXION

M AQUIN A

VIRTUAL

Sistema

Operativo

M AQUIN A

VIRTUAL

Sistema

Operativo

HIPERVISOR

HARDWARE

SISTEM A

OPERATIVO

Contenedor

SISTEM A

OPERATIVO

Contenedor

HARDWARE

CPU

RAM

I/O

CPU

RAM

I/O

MAYOR AISLAMIENTO

MAYOR FLEXIBILIDAD

Fuente: VICTOR, Jeff. SAVIT, Jeff. COMBS, Gary. HAYLER, Simon. NETHERTON, Bob. Oracle Solaris 10 2006. 26 Pág. En la figura 6, muestra un ejemplo del sistema fue adecuado para las cargas de trabajo de la empresa, proporciona alta disponibilidad en los servicios instalados en las máquinas de los centros de datos. Cada partición tiene un control completo sobre el hardware, como se indica en el primer nivel de virtualización para el almacenamiento de los datos. En el otro extremo de la partición, la virtualización del sistema operativo tiene configuraciones con mayor flexibilidad y menor aislamiento en el entorno virtual. Estos son llamados Contenedores o Virtualización nivel 2. Los contenedores proporcionan mejor estabilidad al momento de configurar los servicios en las máquinas virtuales. Entre esos dos extremos, las máquinas virtuales generan la ilusión de tener muchos equipos presentes, sin embargo solo se utiliza una computadora y el software. En la capa donde está el hipervisor, proporciona acceso multiplexado de cada instancia del sistema operativo con el hardware

4 RITCH, Miller. YAHOO RESTRUCTURING.Data Center Knowledge.2012.

35

compartido y tiene la capacidad de instalar, iniciar y detener cada uno de esos casos. Al tener los sistemas virtualizados, se puede tener varios sistemas operativos simultáneamente, la ventaja es que tiene la capacidad de comportase como otro sistema operativo en un mismo ambiente. En el centro de datos de San Fernando está instalado el sistema operativo Solaris 10, es un sistema de tipo Unix, desarrollado desde 1992 inicialmente por Sun Microsystems y actualmente por Oracle Corporation como sucesor. En un tiempo se planeó la compatibilidad para el Itanium (Una de las versiones pasadas de Solaris), pero nunca se llegó al mercado. Al aplicar la virtualización y el sistema operativo en los centros de datos, se relaciona la continuidad con la disponibilidad en virtualización y un sistema activo libre de caídas. La ventaja es la integración con distintos sistemas de almacenamiento y la implementación de máquinas virtuales (VMS), para gestionar y automatizar un plan de recuperación ante desastres de forma ágil, dinámica y funcional. Sin embargo, debido a que el diseño y desarrollo para establecer planes de contingencia, se relaciona directamente con la replicación entre dos sistemas de almacenamiento, cada uno de ellos ubicado en un centro datos diferentes. El principal que es San Fernando queda como origen del entorno de producción y el secundario que es el de Limonar queda como destino. Por otro lado, para implementar un plan de recuperación ante desastres, es posible analizar otras opciones que pasan por la generación de la SAN extendida y la LAN extendida entre los distintos centro de datos, donde se construyó y quedó por parte de la empresa un centro de datos activo – activo, para la alta disponibilidad de los servicios. El centro de datos de San Fernando, tiene la configuración de un clúster extendido entre los hipervisores, con propio sistema de almacenamiento como datastore* compartido entre ambos centros de datos, que funciona únicamente en uno de ellos. Esto es el punto de fallo de mayor impacto ya que la caída del rack de almacenamiento requiere que se disparen procesos de respaldo tradicionales, ya sean manuales o automatizados. Esto implica la aceptación de un tiempo de parada en la prestación del servicio y posterior restablecimiento con un rendimiento al 100%.

36

El centro de datos de Limonar, tiene el balanceo de cargas y la alta disponibilidad de los productos, que se ejecutan en las máquinas virtuales dentro de cada clúster* local de hipervisores. El balanceo debe ser riguroso para conseguir la distribución, donde los pesos de los dos sitios sean del 50% con el propio sistema de almacenamiento como el datastore que no es compartido entre ambos centros de datos. La ventaja principal es que el servicio va a estar protegido ante la caída de los hipervisores que conforman el clúster local, sino que además está cubierto ante la caída del sistema de almacenamiento de forma directa, sin la necesidad de activar ningún proceso automático o manual. El último esquema es compatible con soluciones que automatizan planes de contingencia tradicionales. Esto se debe a que hay una sincronización en los equipos y datos que se utiliza para regresar a un estado anterior conocido como “Error durante la sesión”. Si los datos se envían a un host remoto y se imprime la información, un fallo en esta puede hacer que se pierda un mensaje ya confirmado al emisor. Si se divide el mensaje en los puntos de sincronización, se pueden confirmar y volver a trasmitir el mensaje. Los usuarios pueden insertar puntos de sincronización durante una sesión. Cada punto lleva un número identificativo. Cuando un extremo pide un punto de sincronización el otro recibe una indicación, al igual cuando un extremo pide volver a sincronizar, el otro recibe una indicación5. 5.1.4. Servicios. En el centro de datos de la sede de El Limonar están implementados 14 servicios, que forman parte del complemento para el producto de Internet Banda Ancha ofrecido por Emcali: • AAA (Authentication, Authorization, Accounting). • LDAP (Lightweight Directory Access Protocol). • DHCP (Dynamic Host Configuration Protocol). • Gestión ADSL (Asymmetric Digital Subscriber Line Management). • Ticket (Damage Report). • NTP (Network Time Protocol). • DNS (Domain Name System). • Syslog (Standard for Computer Data Logging). • SNMP (Simple Network Management Protocol).

5 LA SINCRONIZACION. Protocolos de Información. Herramientas WEB. Evirtual Tutorial. 2008.

37

• Hosting (File Storage). • Data Base (Information Storage). • SMTP (Simple Mail Transfer Protocol). • POP (Post Office Protocol). • IMAP (Internet Massage Access Protocol). Para el proyecto, se centró sólo en 3 servicios con el fin de tener un alcance real en el trabajo, para que no se fuera a desbordar los objetivos a medida que se avanzaba en la resolución de la problemática. Los 11 servicios restantes fueron migrados en los centros de datos sin actualización alguna.A partir de este contexto, la empresa mejoró los servicios AAA, Gestión ADSL y Ticket, con esto se logró una alta disponibilidad, calidad y eficiencia. No se manipuló el código o la sintaxis de los aplicativos relacionados. Para mayor entendimiento a continuación se definen el estado de los servicios AAA, Gestión ADLS y Ticket, en el capítulo 4 y 5 se mostrarán la actualización que se aplicó a estos servicios.

• AAA: el aplicativo AAA (Authentication, Authorization, Accounting), es el servicio de control de usuarios cuya función es autenticar, autorizar y acreditar cada petición para el acceso a internet banda ancha. El proceso de autenticación solicita la identidad del cliente mediante un usuario y contraseña para el acceso valido al servicio. El proceso de autorización comprueba los datos del cliente para proporcionar el servicio. El proceso de acreditación se encarga de realizar el seguimiento del consumo de los recursos por usuarios del producto6 .

• TICKET: el aplicativo de Ticket está diseñado con el objetivo de tener en una forma ordenada, los reclamos que se reciben por parte de los usuarios del producto de Banda Ancha. Recibe el reporte de un daño por parte de un cliente. A partir del diagnóstico se envía el ticket al departamento encargado de solucionar el problema. Por esta razón, cada dependencia clasifica los casos a resolver según el causal. Con este proceso, se tiene el historial de los reportes realizados de cada cliente7 . 6 ARAQUE, Carlos Alberto. TRUJILLO, Armandy. VITTA, Juan Carlos. Control Servicio AAA. Noviembre 2009. Santiago de Cali. EMCALI. 11 Pág. 7 ARAQUE, Carlos Alberto. Manual de usuario Aplicación Ticket v1.0, http://ticket.emcali.net.co. Marzo 2010. Santiago de Cali. EMCALI.18 Pág.

38

• Gestión ADSL: el aplicativo gestiona las transacciones efectuadas con los clientes que contratan el servicio de Banda Ancha de Emcali, es una herramienta que controla todo el proceso de contratación e instalación del producto. Tiene el módulo de Gestión Clientes que muestra toda la información de un usuario, este consiste en mostrar el plan de Línea Básica, Banda Ancha y Televisión contratado por el cliente. El módulo de Instalaciones, es donde se asocia al contrato un instalador que debe ir al sitio para instalar los dispositivos para que el cliente consuma el servicio. La ciudad está dividida por dos grupos de contratistas, el Grupo 1 que está relacionado a COMERTEL y el Grupo 2, que está relacionado a IPTEL. El Grupo 1 abarca todas las instalaciones de la parte centro, norte y oriente de la ciudad de Cali y el Grupo 2 abarca las instalaciones de la parte sur y oeste de la cuidad. En él se muestra toda la información del instalador y el tiempo que se demora en cerrar una instalación por día. El módulo de Bodega, es la base de datos de todos los recursos físicos para ser instalados a los usuarios, está cuantificada la cantidad de CPE y STB que tiene cada grupo de contratistas para subastar las instalaciones pendientes, la búsqueda se realiza por la dirección MAC que tiene asociada cada equipo. Para finalizar está el módulo de Retención de Usuario, que consiste en aplicar las promociones y descuentos realizados al cliente, este tiene una conexión directa con el proceso de facturación para seleccionar unas reglas implementadas, que son: obsequiar servicios, aumento de velocidad en Internet Banda Ancha y un descuento hasta del 40% de la facturación del producto contratado. Esto ayuda mucho para que el cliente no cancele el contrato con Emcali Telecomunicaciones8. 5.1.5. Equipos de almacenamiento. Al realizar la explicación sobre los centros de datos, los servicios, virtualización y sincronización, se pasa a los equipos que están disponibles en el centro de datos de San Fernando. Son máquinas virtuales que conforman la nueva plataforma, a continuación son nombradas. • Servidores: Son los equipos usados para el complemento de la

plataforma, a continuación se hace la referencia de cada uno de ellos.

8 GALLEGO, Edinson. YEPES Diego. Manual de usuario Gestión ADSL. Marzo 2009. Santiago de Cali. EMCALI.38 Pág.

39

SunBlades 6000: Blade o chasis de almacenamiento de las tarjetas (Slots) o Sparc de servidores virtuales9 . Ver figura 7. Figura 7. Chasis SunBlades 6000

Fuente: Fotografía Equipos de los Centros de Datos de Emcali. SunBlades - Sparc T6340: Modulo de servidor con alta capacidad de procesamiento virtual, es una tarjeta compacta para generar mejor arranque de conexión10 . Ver figura 8. Figura 8. Sparc T6340

Fuente: Fotografía Equipos de los Centros de Datos de Emcali. • Almacenamiento: son los equipos de almacenamiento y Backup de la

información. A continuación se hace referencia de cada uno de ellos. SAN (Storage Area Network): Red de Área de Almacenamiento, es una red para conectar servidores, matrices de discos y librerías de soporte11. Ver

9 SUN BLANDE 6000, Server Module. Sun Microsystem, Inc. Santa Clara, CA USA. Diciembre 2009.100 Pág 10 INSTALACION Y ADMINISTRACION DEL MODULO DE SERVIDOR SUN BLADE T6340. Sun Microsystem, Inc. Oracle Corporation. Indiana USA. Diciembre 2008. 78 Pág.

40

figura 9. El área está divida en dos partes, la superior donde se encuentra el almacenamiento y en la parte inferior donde están los discos sincronizados. Figura 9. SAN

Fuente: Fotografía Equipos de los Centros de Datos de Emcali. Storage 7410: Es un sistema de alta gama de almacenamiento, ofrece una gestión simple para almacenar información, capacidad de escalabilidad que esta alrededor de 570 TB y ofrece un rendimiento mayor a un consumo de energía menor12. Ver figura 10. Figura 10. Storage 7410

Fuente: Fotografía Equipos de los Centros de Datos de Emcali. Algunas características técnicas son las siguientes. • Procesardor: 2.2 Ghz Six-Core CPU por Controlador. • Memoria: 256 Gb por Nodo. • Cache: 600 Gb por Nodo.

11 SUN BLANDE SAN, Server Module. Sun Microsystem, Inc. Santa Clara, CA USA. Diciembre 2009. 230 Pág 12 SUN BLANDE Storage 7410, Server Module. Sun Microsystem, Inc. Santa Clara, CA USA. Enero 2008. 230 Pág.

41

• Sistema Operativo: Oracle Solaris. Array J4400: Es una matriz de discos para proporcianar alta disponibilidad y almacenamiento virtual13 . Ver figura 11. Figura 11. Arrays 4400

Fuente: Fotografía Equipos de los Centros de Datos de Emcali. Algunas características técnicas son las siguientes. • Puertos: Cantidad 3 de 3 Gb en cada módulo. • Sistema operativo: Solaris. • Soporte para mezclar unidades de cualquier tipo en un solo rack. • Escalable a 48 unidades de disco duro con 4 matrices interconectadas. Este tipo de máquinas permiten la virtualización en nivel dos, esto quiere decir, que está en diferentes capas. La primera capa son los contenedores y la segunda capa son las Zonas Solaris de almacenamiento de los servicios. Esto minimiza el espacio físico y aumenta el espacio virtual para la disponibilidad de los recursos.

13 SUN BLANDE Array J4400, Server Module. Sun Microsystem, Inc. Santa Clara, CA USA. Enero 2008. 100 Pág.

42

6. METODOLOGIA La metodología que se usó para desarrollar el proyecto fue la “Metodología de Desarrollo de Proyectos” (MDP). Con ésta metodología se procede a realizar la descripción, recolección y análisis de la información. Es un método flexible que permite ajustes de acuerdo a las circunstancias requeridas para el desarrollo de un proyecto. El proyecto que se desarrolló, se resolvió por medio de ejercicios o tareas. Primero se recolectó por medio de un trabajo de campo, datos e información que permitan identificar el comportamiento de los servicios y los procedimientos de los centros de datos, para hacer un diagnóstico de la situación actual y realizar el proceso de actualización, migración y sincronización de los servicios hacia la nueva plataforma.

43

La metodología se ajustó al plan de trabajo que ya tenía implementada la empresa, para el progreso del proyecto propuesto. Los rangos de tiempo de las tareas se afectaron por inconvenientes presentados a lo largo de la ejecución del proyecto. La metodología comprende la resolución de los siguientes 9 ejercicios- • Ejercicio 1. Diagnosticar: conocer el comportamiento de los centro de

datos de EMCALI Telecomunicaciones e identificar el funcionamiento general de los servicios AAA, Gestión ADSL y Ticket.

• Ejercicio 2. Analizar: analizar la información adquirida del diagnóstico inicial, el propósito era identificar las mejoras que se realizarían en cada uno de los servicios.

• Ejercicio 3. Actualizar los Servicios: se procedió a implementar las mejoras para la optimización y se analizó el comportamiento de los servicios.

• Ejercicios 4. Roles: identificar con el equipo de trabajo las actividades críticas en el proceso de migración. Se determinó las tareas que desempeñan el Web Master y el estudiante en pasantía.

• Ejercicio 5: Trabajo en piso: proceder a migrar y sincronizar los servicios en el centro de datos de San Fernando. Se realizó simultáneamente pruebas de la red de transporte y de la redundancia en los servicios. Se documentó las actividades realizadas en la migración de los servicios con el fin de levantar los procesos.

• Ejercicio 6: Analizar la documentación con el equip o de trabajo: la primera actividad de piso fue revisar la documentación de los procesos y procedimientos con los integrantes del equipo de trabajo. Se verificó los detalles obviados en la recolección de la información y se estableció el procedimiento estándar para futuras migraciones de servicios en los centros de datos.

• Ejercicio 7: Verificar del Plan de Acción: verificar la efectividad del plan de acción. Se realizó pruebas de la migración, se continuó la documentación realizada por parte del equipo de trabajo.

• Ejercicio 8: Analizar y Documentar los nuevos proce dimientos: se realizó la segunda actividad en piso, se analizó el resultado obtenido después de la actualización, migración y sincronización de los servicios. Se identificó fallas que impidieron el desempeño satisfactorio del plan de acción. Se corrigieron los nuevos procedimientos por el equipo de trabajo.

• Ejercicio 9: Panel para la Presentación de los Resu ltados: se entregó el documento con los procedimientos al Director de Ingeniería, Coordinador y Jefe de Área de Operación y Mantenimiento de EMCALI.

44

Se divulgó la información a los ingenieros de soporte de los procesos realizados.

Los ejercicios 1 y 2, se exponen en el capítulo 3 del documento, en donde se aloja toda la parte de investigación y análisis previo al desarrollo del proyecto. El ejercicio 3, se expone en el capítulo 4, que muestra las mejoras que se hacen en los servicios y en los centros de datos. El ejercicio 4, los roles estaban definidos antes de iniciar el proyecto de pasantía. El ejercicio 5, se expone en el capítulo 5, en donde se documenta la reinstalación de los servicios. Los ejercicios 6 y 8, están relacionados con el capítulo 8, en donde se clasifican los procedimientos de operación y mantenimiento de los procesos de calidad. El ejercicio 7, se expone en el capítulo 7, en donde están los resultados obtenidos en el desarrollo del proyecto. El ejercicio 9, está relacionado con la sustentación del trabajo en la empresa.

7. ACTUALIZACION DE LAS POLITICAS DEL AAA Para mejorar la calidad del producto de Internet Banda Ancha, se procedió a actualizar el flujo de las políticas implementadas anteriormente con el fin de optimizar el desempeño del servicio AAA.

7.1. SERVICIO AAA (AUTENTICACION, AUTORIZACION Y ACREDITACION)

45

Durante el proceso de autenticación de un usuario de Banda Ancha, se cumple una serie de requisitos para la conexión a internet. En este proceso el usuario establece comunicación punto a punto con el equipo BRAS y pasa a través de un DSLAM. El cliente envía parámetros de autenticación usuario y la contraseña, a través del protocolo PPPoE, esto dará inicio a la máquina de estados de autenticación. El BRAS recibe la petición del cliente y establece la comunicación con el servidor para autenticar, autorizar e iniciar el cobro por el servicio de banda ancha. Al evaluar el estado de las pasadas políticas de autenticación, autorización y acreditación (AAA) para los usuarios de Banda Ancha, se diseñó el nuevo policyflow que involucró parámetros físicos de cada puerto de usuario donde marcó la diferencia del esquema anterior, que usaba solo el usuario y la contraseña para la autenticación. Para lograr el nuevo sistema del AAA se implementó el protocolo PPPoE+ (Nas-port-id) en los DSLAM, donde se habilitó el puerto con el protocolo, además del formato de la trama y algunas configuraciones en los puertos de subida al Switch. Para garantizar que la conexión asigne los parámetros de acceso a Internet, en el proceso pasado del AAA los usuarios de Banda Ancha se autenticaban solo con el usuario y la contraseña, para permitir el uso de un mismo usuario desde distintos puerto xDSL referentes al mismo anillo de internet. Con la activación del protocolo PPPoE+ es posible crear nuevas políticas de AAA, que permitan establecer control físico de los puertos de xDSL, esto limita que cada cliente solo pueda establecer la conexión a través del puerto contratado. En cada DSLAM de la Red Multiservicios de Emcali (RMS), se habilitó el protocolo PPPoE+ en modo global, se verificó que los puertos de subida al Switch asignados, concordaran con los definidos en la configuración del PPPoE+.

46

En el software del AAA, existe la posibilidad de crear un flujo que permite al operador implementar unas políticas personalizadas de la autenticación, autorización y acreditación. En el anterior flujo de autenticación y autorización cumple con las siguientes características: • La base de datos LDAP tiene tres servidores, un servidor que es el

maestro y dos servidores que cumplen con la función de esclavos para el almacenamiento de los datos.

• En caso de no encontrar el usuario del cliente, se conecta como usuario soporte que es leído desde el registro del LDAP.

• Se toma la contraseña o la VLAN como parámetros de autentificación en caso de ser indicado en el registro de LDAP.

• La asignación de la dirección IP tiene tres posibles mecanismos:

� Tener una dirección IP fija. � Declarar un parámetro de que el BRAS tome la Dirección IP. � Dejar que el BRAS tome una Dirección IP por defecto.

• Las conexiones desde la plataforma de GPRS se autentican con la Línea

Básica contratada por el usuario, esto quiere decir que el usuario tendrá un dispositivo GSM con la Línea Básica.

El nuevo flujo de autenticación y autorización, tiene las siguientes características: • La base de datos LDAP tiene tres servidores, un servidor que es el

maestro y dos servidores que cumplen con la función de esclavos para el almacenamiento de los datos en forma redundante.

• En caso de no encontrar el usuario del cliente, se conecta como usuario soporte que es leído desde el registro del LDAP.

• El usuario soporte es leído desde un archivo de texto interno para evitar las consultas a LDAP

• Por defecto se autentica por la información del puerto proporcionado por protocolo PPPoE+.

• En caso que la información del protocolo PPPoE+ no tenga un formato válido, se autentica con el comportamiento anterior del protocolo PPPoE.

• La asignación de la dirección IP tiene tres posibles mecanismos:

� Tener una dirección IP fija. � Declarar un parámetro de que el BRAS tome la Dirección IP. � Dejar que el BRAS tome una Dirección IP por defecto.

47

. • Se guarda en el LDAP la información de cual MAC se conectó en cada

puerto. Ventajas que tiene las mejoras de las políticas de autenticación del AAA, es tener un orden y control de cada conexión de los clientes que contratan el servicio. Esto facilita el estudio de las zonas geográficas y saber en qué parte está instalado el servicio, con el tipo de producto contratado. A continuación de muestra el procedimiento técnico que se realizó para la implementación del servicio AAA.

7.2. PROCEDIMIENTO DE EJECUCION DEL AAA

• Inicio de ventana de mantenimiento: en este proceso se planeó con anticipación una reunión para definir la fecha y la hora en la que se realizará la migración a la nueva plataforma. En este caso los horarios en el que se realizó fueron en la madrugada. Está estipulado que las ventanas de mantenimiento oscilen entre las 2 AM y 5 AM, el motivo del horario es porque hay unas horas de alto tráfico en el servicio, para este caso está entre 9 AM y 1 PM en el horario del día y en el horario de la noche está entre 7 PM y 11PM. Esta ventana de mantenimiento se ejecutó a las 3 AM en la Sede de San Fernando y el procedimiento que duró aproximadamente 6 horas. Estos procedimientos se trabajan bajo el sistema operativo Solaris.

• Generar la base de datos de clientes (LDAP): se creó un Script que permitía extraer la información que se encuentra almacenada en la base de datos de MySQL, para generar un archivo se realiza en el formato LDIF, este es un formato que se utiliza para la importación y exportación de información para un servidor de Base de Datos. En la figura el archivo que se generó fue importado al servidor LDAP. En la figura 12 se muestra por medio de la consola como se activa el archivo para ser usado cuando se vuelvan a habilitar las bases de datos en las ZONAS instaladas.

Figura 12. Creación del archivo de la Base de Datos

48

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2013. • Subir base de datos de los clientes al nuevo LDAP: luego de tener el

archivo con la información almacenada, se importa al servidor LDAP maestro. En la figura 13 se detalla la forma como muestra el copiado de la información en la ZONA asignada para la base de datos de AAA.

Figura 13. Subida del Servicio LDAP.

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2013. En la figura 14, se muestra el final de la operación de copiado de la base de datos. Figura 14. Finalización de la Subida de la Base de Datos

49

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2013. En la figura 15, se muestra el proceso terminado, el porcentaje, la velocidad que realizó la operación y el tiempo de duración. Figura 15. Datos Técnicos de la Subida de la Base d e Datos del AAA

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2013. • Configurar la réplica del LDAP: al tener el archivo LDIF en el Servidor

del LDAP maestro, se deshabilita el servicio LDAP, este proceso se hace con el ingreso a la plataforma y se ejecuta el comando “svcadm disabled (Nombre del servicio)”, encargado de deshabilitar el servicio de Solaris. Luego se copia la información de los archivos que fueron creados en el servidor maestro y se realiza una copia a los servidores esclavos. Con el comando “svcadm enable (Nombre del Servicio)” como se muestra en la figura 16, se habilita de nuevo el servicio. Con esto quedaran los servidores con la información que se extrajo de la base de datos y los servicios migrados. Este procedimiento de migración dura alrededor de tres horas en todos los servidores.

Figura 16. Habilitar y Deshabilitar el Servicio par a la Configuración de la Réplica del LDAP

50

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2013. • Pruebas de funcionamiento de LDAP: las pruebas de funcionamiento

consisten en modificar un registro desde el cliente LDAPAdmin, En la figura 17, se observa los parámetros de un puerto con toda la información técnica. El parámetro que se editó para realizar la prueba fue “Emcali Aom Pruebas Larga Distancia”.

Figura 17. Prueba de Edición en el Servidor Maestro del LDAP

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2013. En la figura 18, se evidencia la replicación del parámetro editado en el programa.

51

Figura 18. Replicación de los Datos del Servidor M aestro y Servidor Esclavo

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2013. • Cambio de direcciones IP en SIGT para que escriba e n el nuevo

LDAP: en la figura 19, se muestran los parámetros para cambiar la dirección IP del servidor maestro. Se ingresa al aplicativo de SIGT que está ligado con la base de datos y se comprueba que se tiene acceso.

Figura 19. Cambio de IP's

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2013. • Fin ventana de mantenimiento de SIGT: para finalizar la ventana de

mantenimiento, se modificó la dirección IP con la nueva configuración y

52

se comprobó que en el servidor de producción se realizaron los cambios. Con esto se procede a realizar los movimientos en los BRAS para que autentiquen con la nueva configuración.

• Movimiento en los BRAS para que autentiquen con los nuevos AAA:

en la figura 20, se muestra el ingreso al BRAS para modificar las direcciones IP correspondientes al AAA, este proceso se debe hacer uno por uno por cuestiones de seguridad y no ir a afectar algún BRAS.

Figura 20. Cambio de IP en el BRAS

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2013. • El movimiento es un BRAS a la vez: las modificaciones se realizaron a

los 5 BRAS, ellos están ubicados en la Telefónica de San Fernando, Colón, Guabito, Parcelaciones y Versalles. Ellos tienen implementado el servicio del AAA, cada movimiento dura alrededor de 20 minutos para aplicar la nueva configuración.

53

8. ACTUALIZACION EN LA VIRTUALIZACION DE GESTION AD SL Y TICKET.

La implementación que se realizó para los aplicativos de Gestión ADSL y Ticket fue actualización en el nivel de virtualización 2, para minimizar el espacio físico y optimizar los tiempos de navegación de los aplicativos. Con esto hacen que sean eficientes y rápidos en el momento de las consultas por el lado de los clientes. En la figura 21, Se muestra la ubicación con la actualización en la virtualización de los aplicativos. Se adquiere un Blade o tarjeta (Slot) de virtualización y en el interior se observan los LDOM, en los LDOM 0 y 1, el cual almacena dos contenedores de Zonas Solaris o nivel de virtualización 2, cada uno. En las ZONAS están albergados los aplicativos de AAA, Gestión ADSL y Ticket. Antes de configurar los servicios de este modo, no había replica en la base de datos (DB) lo que aumentó el desempeño de los aplicativos. Figura 21. Ubicación de los Aplicativos en el Siste ma

BLADE

LDOM_0 LDOM_1

ContainerContainer

Gestión ADSL

ContainerContainer

AAA

TICKETBDBD

BDBD

Fuente: Emcali. Certificación Emcali 1.5.3. 2012. Con el fin de virtualizar los aplicativos se encontraron soluciones de almacenamiento, distribuido en los dos LDOM’s que se configuraron y donde se instalaron los servicios de forma redúndate para la continuidad y evitar que en algún momento los servicios queden por fuera de producción por la falta de redundancia en la información.

54

Para que este diseño sea óptimo primero se asignan los recursos informáticos: • Cantidad de Disco. • Cuanto procesamiento se le asignará. • Cantidad de memoria RAM. • Cuantas dirección direcciones IP’s se usaran.

A partir de esta asignación informática, se procede a crear las máquinas virtuales, en este caso serían los LDOM’s y las ZONAS Solaris. • Crear los LDOM’s: para este caso se define un procedimiento para la

creación de los LDOM’s en el Blade. En el diagrama de flujo que se muestra en la figura 22, en ella se detalla el procedimiento técnico de la creación de un LDOM para implementar en el slot que fue definido para instalar los servicios en las ZONAS. Al tener el LDOM instalado se procede a crear la ZONA. Al definir dos LDOM´s, en el diseño, para cada uno de ellos irá dos ZONAS Solaris.

Figura 22. Proceso de creación de un LDOM

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012.

55

• Crear ZONA Solaris: al igual que los LDOM’s, se hace la creación de las ZONAS, este es el contenedor donde se almacenarán los servicios junto con las bases de datos que cada uno hace uso de ellas. A continuación en la figura 23, se muestran los pasos técnicos realizados para la creación de una ZONA. Como el diseño muestra que por cada LDOM se crearan dos ZONAS, se realiza el mismo proceso, en total fueron creadas 4 ZONAS.

Figura 23. Proceso creación de una ZONA

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012. • Implementar la creación de los LDOM’s: después de tener los LDOMs

y las ZONAS creadas en el Blade, se tiene que iniciar el LDOM para

56

poder migrar las ZONAS que fueron creadas exclusivamente para los servicios definidos en el diseño. En la figura 24, muestra el diagrama de flujo con los pasos técnicos que se usaron para dar paso al arranque del LDOM para continuar con el proceso de virtualización.

Figura 24. Proceso para Iniciar un LDOM

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012. • Migrar las ZONAS: al iniciar el LDOM queda listo para dar paso a la

migración de las 4 ZONAS que ya fueron creadas, en la figura 25 está el diagrama de flujo que muestra los pasos técnicos que se realización con cada una de las ZONAS para ubicarlas dentro de los LDOM’s y dar paso proceso de copiado de los datos en la plataforma.

Figura 25. Proceso para Migrar una ZONA

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012.

57

Al tener listas las maquinas con los LDOM’s y ZONAS creadas, por otro lado se hace la instalación de los servicios MySQL y Apache para los aplicativos Gestión ADSL y Ticket. Como son aplicativos Web, es necesaria la instalación de estos servicios. Se tienen listos los pasos anteriores se migran las base de datos, antes de instalar los servicios. Antes de migrar a las ZONAS, se realizan las pruebas de los servicios Gestión ADSL y Ticket en los servidores de pruebas y de producción.Para realizar las pruebas del aplicativo de Ticket se usó el Servidor de Pruebas y el Servidor de Producción para la carga de datos, se configuró con una concurrencia de 250 usuarios que ejecutan la entrada al aplicativo simultáneamente. Como primer paso consultan la lista Terreno AGC (Listado de Tickets del Área de Atención al Cliente), luego la lista Terreno AR (Listado de Tickets del Área de Atención Residencial) y finalmente la lista de diagnosticó Banda Ancha. Para automatizar la prueba se utilizó la herramienta JMETER, se tuvo en cuenta los diferentes atributos para comparar el rendimiento de la aplicación en el Servidor de Producción con el Servidor de Prueba. La ampliación de este proceso se muestra en el capítulo de resultados. Para realizar las pruebas del aplicativo Gestión ADSL se usó el Servidor de Pruebas y el Servidor de Producción para la carga de datos, se configuró con una concurrencia de 100 usuarios que realizan la entrada al aplicativo simultáneamente. Como primer paso se consulta el Menú, luego Consultar la Orden y finalmente la lista de Instalaciones. Para automatizar la prueba se utilizó la herramienta JMETER, se tuvo en cuenta los diferentes atributos para comparar el rendimiento de la aplicación en el Servidor de Producción con el Servidor de Prueba. . La ampliación de este proceso se muestra en el capítulo de resultados. Con toda esta información lista, se generan los procedimientos de ejecución hacia las ZONAS para ser puestas en producción.

58

8.1. PROCEDIMIENTO DE EJECUCION DE LA APLICACION GE STION ADSL O SIGT

• Inicio de ventana de mantenimiento: la ventana de mantenimiento se

realizó a las 2:00 AM para que no se viera afectado el servicio por parte del cliente y no fuera a generar degrado de la información. Para el procedimiento se usó el sistema operativo Solaris, el cual está ligado a las maquinas Oracle que se implementaron en los centros de datos.

• Hacer Backup de las bases de datos: en la figura 26, se muestra el

ingreso a la base de datos MySQLy con el comando “mysqldrump”, se realiza el Backup de la información para ser migrada a los servidores de la nueva plataforma. La base de datos para SIGT se llama GESTION_EMCALI, como se muestra en las líneas de comandos del sistema operativo Solaris que se ejecutaron en la consola para el guardado de la información.

Figura 26. Proceso de Backup de la Base de Datos

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2013.

59

• Hacer Backup del código de SIGT: en la figura 27, se muestra como se genera el archivo para la creación del Backup del código de SIGT o Gestión Servicios para dejarlo listo para configurarlos en las ZONAS implementadas en la nueva plataforma de virtualización.

Figura 27. Backup de la Base de Datos de Gestión AD LS

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2013. • Mover información a las nuevas zonas: en la figura 28, se muestra el

movimiento que se realizó del archivo para ser implementado ZONA creada para almacenar el servicio de Gestión ADSL, esto es realizado con el comando “ssp (nombre del archivo)”, se ingresa a la ZONA y se realiza el traslado de la información. Luego se habilita de nuevo la Base de Datos en la consola para tener el proceso terminado en la migración a las ZONAS.

60

Figura 28. Movimiento de Información a las ZONAS

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2013. • Configurar replicación: para poner de nuevo la replicación a funcionar

se realizó el siguiente proceso técnico después de tener lista la información anterior:

� Se baja la replicación en el esclavo (aplicaciones_GestionADSL_mgm_a)

STOP SLAVE. � Se obtiene la información replicada desde el maestro. � Se consultó el actual archivo de log del mysql maestro, en la consola de

mysql del servidor de BD, con el comando: SHOW MASTER STATUS;File: mysql-bin.0000181 row in set (0.01 sec).

� Se sube nueva información en GESTION_EMCALI, se entra por consola a la Base de Datos.

61

� Se actualiza en el esclavo la información del log actual y la línea en la que se encuentran sincronizadas la Base de Datos.

• Subir código de Gestión y Movimiento de la Direcció n IP: luego de

tener los archivos, se ejecuta el traslado de la información en la ZONA para que quede almacenada y colocar en producción el aplicativo, este cambio de direcciones IP se realiza para que no genere conflicto en el aplicativo en el momento de ser usado el aplicativo.

• Pruebas de funcionamiento: se ingresa al aplicativo por medio de la

URL http://adls.emcali.net.co y se comprueba que este cargando rápidamente todos los módulos. Ver figura 29.

Figura 29.Interfaz de Usuario de GESTION ADSL

Fuente: Sistema Integrado de Gestión de Telecomunicaciones de Emcali. Emcali Telecomunicaciones. 2013. • Fin ventana de mantenimiento de SIGT: se notifica a los directivos que

el servicio ya quedo migrado y se generan los procesos para operación y mantenimiento de la herramienta.

62

8.2. PROCEDIMIENTO DE EJECUCION DE LA APLICACION TI CKET • Inicio de ventana de mantenimiento TICKET: la ventana de

mantenimiento se realizó después de terminar la migración del servicio Gestión ADSL, en el transcurso de la madrugada para que no se viera afectado el servicio por parte del cliente y no fuera a generar degrado de la información. Para el procedimiento se usó el sistema operativo Solaris, el cual está ligado a las máquinas Oracle que se implementaron en los centros de datos

• Hacer back up de las bases de datos: en la figura 30, se muestra el

ingreso a la base de datos MySQLy con el comando “mysqldrump”, se realiza el backup de la información para ser migrada a los servidores de la nueva plataforma. La base de datos para TICKET se llama DBTICKET, como se muestra en las líneas de comandos ejecutadas en la consola para el guardado de la información.

Figura 30.Proceso de Backup de los Datos

63

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2013. • Mover información a las nuevas zonas: en la figura 31, se muestra el

movimiento que se realizó del archivo para ser implementado ZONA creada para almacenar el servicio de TICKET, esto se hizo con el comando “ssp (nombre del archivo)”, se ingresa a la ZONA y se realiza el traslado de la información. Luego se habilita de nuevo la Base de Datos en la consola para tener el proceso terminado en la migración a las ZONAS.

Figura 31. Movimiento de Información a las ZONAS

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2013. • Configurar replicación: para poner de nuevo la replicación a funcionar

se realizó el siguiente proceso técnico después de tener lista la información anterior.

� Se baja la replicación en el esclavo (aplicaciones_tickets_mgm_a) STOP

SLAVE.

64

� Se obtiene la información replicada desde el maestro. � Se consultó el actual archivo de log del mysql maestro, en la consola de

mysql del servidor de BD, con el comando: SHOW MASTER STATUS;File: mysql-bin.0000181 row in set (0.01 sec).

� Se sube nueva información en BDTICKET, se entra por consola a la Base de Datos.

� Se actualiza en el esclavo la información del log actual y la línea en la que se encuentran sincronizadas la Base de Datos.

• Subir código TICKET y Movimiento de las Direcciones IP: luego de

tener los archivos, se ejecuta el tralado de la información en la ZONA para que quede almacenada y poner en producción el aplicativo, este cambio de direcciones IP se realiza para que no genere conflicto en el aplicativo en el momento de ser usado el aplicativo.

• Pruebas de funcionamiento: se ingresa al aplicativo por medio de la

URL http://ticket.emcali.net.co y se comprueba que este cargando rápidamente todos los módulos. Ver figura 32.

Figura 32. Interfaz de Usuario de Ticket

Fuente: Ticket de Emcali. Emcali Telecomunicaciones. 2013.

65

• Fin ventana de mantenimiento de TICKET: se notifica a los directivos que el servicio ya quedo migrado y se generan los procesos para operación y mantenimiento de la herramienta.

9. REINSTALACIÓN DE LOS SERVICIOS. El resultado de la implementación de la arquitectura diseñada para los centros de datos de Emcali, está compuesta por servidores funcionales, cada uno cumple un rol dentro de la arquitectura. Este análisis surgió por el trabajo de piso que se aplicó durante el desarrollo del proyecto. Los servidores se configuraron a partir de herramientas propias de la plataforma, es decir, con el software que el sistema operativo implementó para estas máquinas físicas y que se diseñó para el nodo de San Fernando. En la infraestructura de servidores, unidades de almacenamiento, switchs, etc. que son el componente tangible del centro de datos, deben estar administrados por el componente humano, para la instalación y actualización de las máquinas y servidores involucrados. A esto, también se suman todos los componentes intangibles de servidores virtuales y almacenamiento virtualizado, que se ha dispuesto para optimizar el uso y productividad de la nueva plataforma. Es natural que en este escenario se establezcan mecanismos que faciliten la administración de toda la infraestructura, que de manera efectiva y eficiente, aporten la rapidez y seguridad necesaria en las actividades de operación y mantenimiento. Aun cuando se tiene en cuenta que la plataforma esta replicada en dos sitios distantes geográficamente, en las sedes: Limonar y San Fernando. Como parte del trabajo de implementación, se diseñó una serie de scripts o de comandos, que ayudan a ejecutar las tareas básicas de mantenimiento requeridas para los servidores virtualizados. A partir del hardware de la plataforma de servidores físicos se encuentran los Dominios Lógicos y las Zonas o Contenedores Solaris. Los primeros alojan a una cantidad determinada de Zonas o Contenedores mientras, que estos últimos, es decir, en las Zonas Solaris, alojan la funcionalidad requerida para

66

los fines que han sido dispuestos, en este caso, el almacenamiento de los tres servicios actualizados. Por otro lado, dentro de las alternativas de interconexión de los aplicativos a la información de los clientes, la tecnología de almacenamiento es NAS, que proporciona mayores beneficios. En el pasado, los centros de datos eran creados alrededor de particiones aisladas de almacenamiento en discos SCSI que eran directamente interconectados a los servidores de aplicativos. Esencialmente la tecnología NAS es la consolidación de las particiones aisladas de almacenamiento en una red de alta velocidad de transferencia de datos, como la provisión de una red privada de almacenamiento basada en 10 GB Ethernet sobre el protocolo iSCSI. Esta tecnología ayuda a incrementar la capacidad de utilización del almacenamiento, debido a que múltiples servidores consolidan un espacio privado en arreglos de discos físicos. Esto incluye la provisión del acceso de los datos que requieren de esas velocidades de transmisión, el nivel de acceso a bloques de datos en discos tales como los servidores de correos, bases de datos y servidores de archivos. Al compartir almacenamiento se simplifica la administración y flexibiliza la instalación, debido a que no hay cambios en el cableado, se reduce las necesidades de mover físicamente datos entre áreas de almacenamiento de un servidor a otro. Otro beneficios permiten que los servidores puedan iniciar la operación desde la misma red, esto genera un rápido y fácil remplazo de caídas. Esta tecnología de almacenamiento facilita de manera más efectiva un eventual plan y procesos de recuperación de desastres, debido a que el almacenamiento podría expandirse hacia múltiples sitios geográficos en sitios alternos y almacenamiento secundario. La economía de la consolidación en arreglos de discos se ha acelerado en varias características funcionales incluyendo la plataforma de catching, de apagado y prendido de las máquinas, el snapshotting, etc. Para acceder a todas esos beneficios y dar la mayor flexibilidad a la infraestructura, se definió que era lo más viable para Emcali en cuestión de costos y reducción de tiempos.

67

A partir de lo anterior se producen reconfiguraciones de los elementos ya instalados para habilitar dichos crecimientos, lo que significa ejecutar procedimientos como parte de la administración de la operación y mantenimiento de los centros de datos, en algunos casos crecimiento físico y nuevas adquisiciones que normalmente son planificadas. Como se puede apreciar en la figura 33, la arquitectura planteada, se extiende entre dos sitios geográficamente distribuidos, los nodos: San Fernando el primero y Limonar el segundo. Figura 33. Arquitectura General

Fuente: Emcali. Certificación Emcali 1.5.3. 2012. En San Fernando se tiene el centro de control activo, esto significa que el monitoreo se llevará a cabo desde el y Limonar quedará como el espejo de replicación de datos. En la parte de replicación se conectan los discos de almacenamiento 7410 con el fin de tener un sistema de almacenamiento en ambos centros de datos. En la gráfica se muestra la arquitectura Solaris con los slots T6340 que fueron configurados para almacenar los servicios y otra arquitectura de los slot X6270, que serán implementados para el servicio de televisión en un futuro. La plataforma de hardware de servidores que compone la arquitectura en cada uno de los nodos, fundamentalmente tiene dos equipos idénticos

68

basados en la tecnología de tarjetas (Slots) de Oracle, uno para cada nodo o sede de Emcali. Estos servidores posee la cantidad de seis tarjetas (Slots) cuya distribución por Sistema Operativo es la siguiente. Ver cuadro 4. Nodos San Fernando y esta replicado en Limonar: Cuadro 4. Distribución de LDOM's y ZONAS SOLARIS

DISTRIBUCION DE SERVICIOS

Número de Slots

BLADE LDOM ZONAS

SOLARIS

1 SAFE_T6340_00

SAFE_T6340_000 Ticket AAA Maestro

SAFE_T6340_001 Correo DNS Gestión ADSL

SAFE_T6340_002 AAA Esclavo DNS

2 SAFE_T6340_01

SAFE_T6340_010 Hosting DNS de Servicio

SAFE_T6340_011

AAA Esclavo AAA Testing DNS Hosting LDAP

SAFE_T6340_012 Correo Backup DNS

Fuente : González Caicedo, Erika Andrea. Asignación de Recursos Emcali Telecomunicaciones. 2012. Cada uno de los servidores físicos tiene caminos duales, habilitados tanto hacia la red pública de servicios, como hacia la red de administración. Igualmente los caminos están habilitados de la misma manera hacia los discos.

69

Los primeros (Red Pública de Servicio y Red Administrativa), son conexiones Gigabit Ethernet (1Gb); mientras que los segundos (Red de Almacenamiento) son conexiones Ten Gigabit Ethernet (10Gb). En relación a la estrategia de consolidación del almacenamiento y como se explicó antes, EMCALI cuenta con unidades NAS con interconexión a estos canales, Ten Gigabit Ethernet, materializados en unidades de almacenamiento Oracle Storage Systems 7410, para ambos nodos o sedes. Todos los servidores virtualizados sobre los físicos se encuentran representados en Dominios Lógicos y Zonas Solaris, como en servidores virtuales OVM 2.2.1, que tienen habilitados los caminos alternos que hacen uso de mecanismos por canales distintos hacia sus correspondientes discos habilitados en el sistema de almacenamiento. Para la reinstalación de los servicios, el primer paso es crear las máquinas virtuales, dentro del sistema operativo se tienen los niveles de virtualización, donde el nivel 1 es la creación de un LDOM y el segundo nivel dentro del sistema operativo es la creación de las Zonas de almacenamiento. A continuación, se muestran los pasos para la creación de cada una de las unidades de almacenamiento. Los diagramas de flujo y los scripts de administración que se usaron para la configuración se muestran en el Anexo A. Los scripts de administración se han clasificado de la siguiente manera • Scripts destinados a la administración de LDOMs en el sistema Operativo

Solaris 10. • Scripts destinados a la administración de Zonas en el sistema Operativo

Solaris 10. También se ha diseñado una subclasificación de los scripts que forman el inventario de herramientas de administración para cada uno de estos grupos, según la funcionalidad a la que van dirigidos en el alcance y objetivo administrativo. De esta manera tenemos los siguientes cuatro subgrupos funcionales de scripts para los LDOMs:

70

• Destinados al manejo del Ciclo de Vida y Administración de LDOMs, • Destinados al manejo Administrativo de LDOMs, • Destinados al manejo Administrativo y Monitoreo de LDOMs, • Destinados al manejo Administrativo y de Mantenimiento de LDOMs, De igual manera se establecieron los siguientes tres subgrupos funcionales de scripts para las Zonas: • Destinados al manejo del Ciclo de Vida y Administración de Zonas, • Destinados al manejo Administrativo de Zonas, • Destinados al manejo Administrativo, de Mantenimiento y Monitoreo de

Zonas. El proceso general para la reinstalación de los servicios consta de los comandos de instalación de la configuración de las Zonas con la diferencia que se remplaza con los nombres originales de los aplicativos implementados.

71

10. ARQUITECTURA DE RED DE LOS CENTRO DE DATOS DE E MCALI Al documentar la arquitectura final de las topologías físicas y lógicas, que se basó en el modelo TCP/IP, para verificar la redundancia y los protocolos usados para el buen desempaño de la arquitectura de red con esto se logró tener un archivo robusto con los detalles implementados de los centros de datos de Emcali. Los diagramas de los centros de datos de Emcali, se dividen por capas o niveles que se representan en las figuras que se verán a lo largo de este capítulo. Los diagramas presentados a Emcali se encuentran en el Anexo B. Por otro lado, al conocer la norma TIA 495 y las necesidades de Emcali Telecomunicaciones, se requiere certificar los centros de datos con base a los niveles de TIER que existen. Por lo anterior, se implementó la siguiente topología, lo cual cumple los requerimientos exigidos para ser aplicada en los dos centros de datos de Emcali. Los ítems que se tomaron como referencia fue confiabilidad, disponibilidad y escalabilidad, ya que van ligados al “Objeto certificado” que es el AAA, conocido así por el estándar de calidad que rige en la empresa.

72

10.1. TOPOLOGIA FISICA A continuación se observa el diagrama de interconexión entre los switchs y los equipos físicos que conforman los centros de datos de EMCALI. Ver figura 34.

Figura 34. Centro de Datos San Fernando y Limonar

Fibra 10G SMFRMS EMCALI

NAS

Fibra oscura 10G SMF

Fibra 10G MMF

Fibra 10G SMF

10GE

10GE

10GE

10GE

NAS

10GE

10GE

10GE

10GE

Fibra 10G SMF

UPSUPS

100/1000 100/1000

Servidor de Backup T 2000

Servidor Control de Acceso

Servidor Control de Acceso

Blades

NODO SAN FERNANDONODO LIMONAR

Fibra oscura 10G SMF

FE 0/23

FE 1

SFD_2960_1

SFD_4900_1

SFD_4900_2

FE 0/24

TEN G 1/1

TEN G 1/1 FE 1

FE 0/24

FE 0/23

FE 1

FE 1

LIM_4900_2

LIM_4900_1

LIM_2960_1

SW ZTE SW ZTE

TEN G 1/1

TEN G 1/1

TEN G 1/2

TEN G 1/2

TEN G 1/2

TEN G 1/2

GE 0/1

GE 3/20

Blades

GE 3/20

GE 0/2

GE 3/20

GE 0/2Trunk

Trunk

GE 0/1

GE 3/20

Trunk

Trunk

Fuente: González Caicedo, Erika Andrea. Microsoft Visio. 2012. En la figura 34, muestra cómo se conforma el cableado estructurado y fibra óptica para la comunicación entre ambos centros de datos. En cada nodo

73

tienen implementados sistemas de energía alterno para evitar paradas inesperadas de energía en sector geográfico. Los Blades, van conectados al sistema de almacenamiento, están implementados en ambos centros de datos. Finalmente estos se conectan con la RMS EMCALI, por medio de los switch de San Fernando y Limonar

10.2. VLAN Una red de área local virtual (VLAN) es un método de crear redes lógicamente independientes dentro de una misma red física. Varias VLAN’s pueden existir en un único conmutador físico o en una única red física. Son útiles para reducir el tamaño del dominio de difusión y ayudan en la administración de la red, a separar segmentos lógicos de una red de área local que no deberían intercambiar datos. Las redes de área local virtuales se pueden clasificar en cuatro tipos. • Nivel 1: Por Puerto: Se especifica qué puertos del Switch pertenecen a

la VLAN, los miembros de dicha VLAN son los que se conecten a esos puertos. No permite la movilidad de los usuarios, se reconfigura las VLAN’s si el usuario se mueve físicamente.

• Nivel 2: Por Direcciones MAC: Se asignan hosts a una VLAN en función de su dirección MAC. Tiene la ventaja de que no hay que reconfigurar el dispositivo de conmutación si el usuario cambia su localización, es decir, se conecta a otro puerto de ese dispositivo.

• Nivel 3: Por Tipo de Protocolo: La VLAN queda determinada por el contenido del campo y el tipo de protocolo de la trama MAC.

• Nivel 4: Por Direcciones de Subred: La cabecera se usa para mapear la VLAN a la que pertenece. En este tipo de VLAN son los paquetes y no las estaciones los que pertenecen a la VLAN.

• Niveles superiores: Se crea una VLAN para cada aplicación: FTP14, flujos multimedia, correo electrónico.

14

FTP (File Transfer Protocol): Permite transferir archivos locales hacia un servidor Web.

74

Durante todo el proceso de configuración y funcionamiento de una VLAN es necesaria la participación de una serie de protocolos entre los que destacan el IEEE 802.1Q, STP y VTP. • Topología Lógica A continuación se observa el diagrama de interconexión entre las VLAN’s y los equipos que conforman los centros de datos de EMCALI. Ver figura 35. Figura 35. Diagrama de enlaces de las VLAN's.

Fuente: González Caicedo, Erika Andrea. Microsoft Visio. 2012. En la figura 35, muestra las VLAN’s 113 y 111, encargadas de interconectar, sincronizar y hacer Backup de las los servicios e implementaciones de las plataformas. En centro de datos está el grupo 4082, grupo de VLAN’s implementadas para Administración Principal, Administración Corporativa, Servicios, Almacenamiento y Sincronización.

75

10.3. SPANNING TREE PROTOCOL (STP). El Protocolo Spanning Tree es un estándar para usar en la administración de redes, se basa en el algoritmo de Árbol Abarcador, describe cómo los puentes y conmutadores pueden comunicarse para evitar Loops o Bucles en la red. Este protocolo automatiza la administración de la topología de la red con enlaces redundantes, la función principal es permitir rutas conmutadas puenteadas duplicadas sin considerar los efectos de latencia de los Loops en la red. El algoritmo calcula una ruta libre de Loops. Las tramas denominan unidades de datos del protocolo puente (Bridge Protocol Data Unit: BPDU), que son enviadas y recibidas por todos los switchs de la red esto denomina la topología configurada del SPT en la red. El PST que trabaja a nivel de MAC, construye un árbol de la topología de la red, comienza desde la raíz o nodo. Uno de los dispositivos STP se convierte en la raíz después de haber ganado la selección, para eso cada dispositivo STP comienza a tratar de convertirse en la raíz del árbol STP mediante el envío de paquetes de datos específicos denominados BPDU a través de todos sus puertos, en el momento que se enciende. La dirección del receptor del paquete BPDU es una dirección de un grupo multicast, esto permite al paquete BPDU atravesar dispositivos no inteligentes como hubs y switches. Después de recibir el paquete BPDU desde otro dispositivo, el puente compara los parámetros recibidos con los propios, depende del resultado si decide seguir o no ser el nodo raíz. Al terminar las elecciones, el dispositivo con el identificador de puente con un valor más bajo será designado raíz. El Identificador de Puente es una combinación entre la dirección MAC del Puente y una prioridad del Puente predefinida. Si se identifica un solo dispositivo STP en la red, éste será la raíz. La raíz Designada no tiene responsabilidad adicional, tan solo es el punto de inicio desde donde se comienza a construir el árbol de la topología de la red. Para todos los demás Puentes en una red, STP define el Puerto raíz como el

76

puerto más cercano al Puente raíz. Los demás puentes se diferencian con su Identificador (combinación de la MAC y la prioridad definida para ese puerto) El Coste de la Ruta raíz (Root Path Cost) también es un valor significativo para las elecciones STP, comienza con la suma de los costes de las rutas: del puerto raíz del Puente dado y todos los costes de las rutas a los puertos raíz de los demás Puentes en la ruta hacia el Puente raíz En adicción al Puente raíz principal STP define una entidad lógica denominada Puente Designado. Este cargo también está sujeto a elección. De manera similar, STP define por cada segmento de red el Puerto raíz Designado (Que es el que sirve en cada segmento de red) y su correspondiente Coste de Ruta. Después de que las elecciones han finalizado, la red entra en la fase estable. Este estado está caracterizado por las siguientes condiciones. • Solo hay un dispositivo anunciando para ser La raíz este informa a todos

los demás puentes periódicamente de que ese nodo es la raíz del árbol. • El Puente raíz envía periódicamente paquetes BPDU a través de todos

sus puertos. El intervalo de envío se denomina 'Hello Time'. • En cada segmento LAN existe un Puerto Designado. Todo el tráfico hacia

el Puente raíz se realiza a través de él, comparado con otros Puentes, es el que tiene el Coste de Ruta menor hacia el Puerto raíz, si los valores son iguales, el puerto con el Identificador de Puerto más bajo es el asignado.

• BPDU's son enviados y recibidos por la unidad compatible con STP de cada puerto, incluye los puertos que están deshabilitados por el propio STP.

Cada Puente reenvía tramas solo entre Puertos raíz y Puertos Designados para los segmentos correspondientes. Todos los demás puertos son bloqueados. Como sigue a esto último, STP administra la topología y cambia el estado de los puertos según la siguiente lista: Bloqueado: El puerto está bloqueado (Se desechan las tramas de usuario), pero se aceptan los BPDU's. Escucha: Primer escenario antes del reenvío. Las tramas STP (BPDU's) son aceptadas, pero las tramas de usuario no son procesadas. No se aprenden

77

direcciones, ya que esto podría introducir datos erróneos en las tablas de conmutación en este momento. Aprendizaje: Segundo escenario de preparación para el estado de reenvío. Las BPDU’s son procesadas por completo, pero las tramas de usuario solo se usan para construir las tablas de conmutación y no son reenviadas. Envío: Todas las tramas son procesadas. En el momento de la reconfiguración de la topología de la red, todos los puertos de los Puentes están en uno de estos tres estados, Bloqueados, A la escucha o Aprende, las tramas de usuario no son entregadas y la red trabaja solo para sí misma, no para los usuarios. En los centros de datos de Emcali el protocolo se implementó de acuerdo a las VLAN´s que se muestran en la tabla 5. Estás VLAN’s son principales porque el tipo de trafico contiene toda la información de los servicios y la sincronización de las plataformas. La nomenclatura esta especificada por los parámetros propuestos por la empresa que es dedicada especialmente para las plataformas. Cuadro 5.Tipo de Trafico de VLAN's

VLAN´s FIBRA TIPO DE TRAFICO

113 Storage 111 Backup y Sincronización 116 Replicación STP

Fuente: Propia. González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012. A continuación se muestran los acrónimos que se manejan en las figuras. • SAFE: Centro de datos de San Fernando. • LIMO: Centro de datos de Limonar • ROOT: Nodo Raíz • DP (Designate Port): Puerto Designado

78

• RP (Root Port): Puerto de ruta principal • BP (Backup Port): Puerto de Backup. • NEM: Switche para conectar las tarjetas o slot con los demás dispositivos

de los centros de datos de Emcali. Como es un protocolo de capa 2, el comportamiento de las VLAN’s está separada por grupos ya que hay dos topologías del protocolo Spanning Tree y se denominan instancias, en este caso están implementadas la 10 y 11 para los centros de datos de Emcali Telecomunicaciones. La diferencia entre ambas gráficas es que los puntos de principales cambian una por ser una principal y la otra la replicación por si llega a fallar la principal. Ver figura 36 y 37. Al estar conectado todo físicamente, en la figura 36, los puntos principales están en SAFE 1 con las líneas verdes, como es un solo dominio de broadcast, puede generar una congestión y que la red puede empezar a tener Loops, esto puede ocasionar la degradación de datos. Si llega a fallar un punto de la línea verde, inmediatamente la línea punteada roja será tomada como principal para la transferencia de los datos y mantener estable la red. El protocolo es usado para evitar que los puntos de conexión colapsen por el paso indeterminado de los datos, este es aplicado para VLAN que va por el Storage o la unidad de almacenamiento que se tiene en la empresa. Figura 36. Spanning Tree de la VLAN 113 en la insta ncia 10

79

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012. En la figura 37, los puntos principales están en LIMO 2, con las líneas verdes y si ocurre algún momento se pierde la conexión, inmediatamente la línea punteada roja se habilitará y será tomada como principal para la transferencia de los datos y la red no tendrá loop en la transferencia de los datos. Este es aplicado para la VLAN de replicación, con vista hacia Limonar ya que el centro de datos de Backup para la empresa. Figura 37. Spanning Tree de la VLAN 116 en la insta ncia 11

80

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012.

11. RESULTADOS Después de implementar las mejoras de los servicios y de ser reinstalados en los centros de datos de Emcali Telecomunicaciones, se verifica el plan de acción que se mostrará con los resultados obtenidos.

11.1. RESULTADOS AAA Al realizar la actualización en la nueva configuración del policyflow, se mejoró el desempeño del aplicativo en las conexiones de los puertos de los

81

usuarios, los dispositivos fueron modificados y los resultados fueron los siguientes. • El 98.2 % de las MSAG fueron Normalizadas, no fue posible conectarse

al restante 1.8% dado que se encontraban sin conexión al sistema de gestión.

• El 95 % de los DSLAM fueron actualizados, no fue posible conectarse al restante 5% dado que se encontraban sin gestión.

• Se diseñó y se implementó en el Radius de prueba el nuevo “policyflow” de autenticación.

11.2. RESULTADOS APLICATIVO TICKET Para realizar las pruebas del aplicativo se usó el Servidor de Pruebas y el Servidor de Producción para la carga de datos, se configuró con una concurrencia de 250 usuarios que ejecutan la entrada al aplicativo simultáneamente. Como primer paso consultan la lista Terreno AGC, luego la lista Terreno AR y finalmente la lista de diagnosticó Banda Ancha. Para automatizar la prueba se utilizó la herramienta JMETER, como se muestra en el cuadro 6, se tuvo en cuenta los diferentes atributos para comparar el rendimiento de la aplicación en el Servidor de Producción con el Servidor de Prueba. Los atributos son: • Principal: Carga la página principal de la aplicación. • Terreno AGC: Carga la página de Atención de Grandes Clientes. • Carga CSS: Carga el formato de las páginas. • Terreno AR: Carga la página de los tickets del área de atención

residencial. • Diagnostico ADSL: Carga la página del contenido de las características

técnicas de los dispositivos de cada usuario. Se obtiene el promedio (PPru y PPro), en milisegundos de ambos servidores para comprobar que el servidor de pruebas, que es el que ya tiene implementado la virtualización, es más eficiente con respecto al servidor de producción. Tiene un tiempo mínimo (TMiPru y TMinPro) de entrada a cada

82

uno de los atributos configurados y al hacer el balance en el cuadro 6, se muestra que el servidor de prueba es más rápido al cargar los atributos. Por otro lado, el tiempo máximo (TMaPru y TMaPro) de entrada a los servidores se redujo a la mitad del tiempo de ejecución para consulta en tiempo real de las implementaciones realizadas en la herramienta administrativa. Cuadro 6. Atributos en la Carga de las Páginas de P ruebas entre los Aplicativos de Pruebas y de Producción

Atributo PPru PPro TMiPru TMiPro TMaPru TMaPro Principal 2285 6993 37 237 50801 194387 Terreno GC 14212 11040 77 127 283602 426272

Carga CSS 5122 1661 17 17 212911 63299

Terreno AR 9034 4848 69 224 230295 112268

Diagnostico ADSL 978 358 72 56 30365 19804

TOTAL 4626 6961 2 2 283602 426272 Fuente: Informe Servidores Emcali. Jmeter. Julio 2012.

Para terminar con la comparación se hace la diferencia entre los valores del promedio (P), el tiempo mínimo (TMi) y el tiempo máximo (TMa) de los atributos medidos de los servidores de Prueba y Producción. Es una operación matemática: ‘Prueba – Producción’, esto muestra los resultados obtenidos en las pruebas realizadas por cada uno de los usuarios, ver cuadro 7. Cuadro 7. Diferencia de Atributos en la Carga de la s Páginas de Pruebas

Atributos Promedio Tiempo Min

Tiempo Max

Principal 2285 -200 -143586 Terreno

GC 14212 -50 -142670

83

Carga CSS 5122 0 149612

Terreno AR 9034 -155 118027

Diagnostico ADSL 987 16 10561

TOTAL 4626 0 -142670 Fuente: Informe Servidores Emcali. Jmeter. Julio 2012. Al comparar el tiempo en milisegundos de los atributos medidos y el tiempo máximo medido en la carga de datos, en general es mayor en el servidor de Prueba, por lo tanto el servicio se puede ver afectado sin embargo el tiempo que había antes de la actualización era de una de duración de 50 segundos y se logró optimizar a 11 segundos.

11.3. RESULTADOS APLICATIVO GESTION ADSL Para realizar las pruebas del aplicativo se usó el Servidor de Pruebas y el Servidor de Producción para la carga de datos, se configuró con una concurrencia de 100 usuarios que realizan la entrada al aplicativo simultáneamente. Como primer paso se consulta el Menú, luego Consultar la Orden y finalmente la lista de Instalaciones. Para automatizar la prueba se utilizó la herramienta JMETER como se muestra en el cuadro 8, se tuvo en cuenta los diferentes atributos para comparar el rendimiento de la aplicación en el Servidor de Producción con el Servidor de Prueba. Los atributos son: • Menú: Carga la página con las diferentes opciones de consulta del

servicio. • Consultar Orden (Cons Or): Carga la página con toda la información del

usuario y la orden de contrato del servicio que quiere contratar. • Cola de Instalación (Cola Ins): Carga la página de la cola de instalación

que tiene cada instalador y el estado en que se encuentra el proceso.

84

Se obtiene el promedio (PPru y PPro), en milisegundos de ambos servidores para comprobar que el servidor de pruebas, que es el que ya tiene implementado la virtualización, es más eficiente respecto al servidor de producción. Tiene un total de reportes mínimo (ToMiPru y ToMinPro) de entrada a cada uno de los atributos configurados y al hacer el balance en el cuadro 8, se muestra que el servidor de prueba es más rápido al cargar los atributos. Por otro lado, el total de reportes máximo (ToMaPru y ToMaPro) de entrada a los servidores se redujo considerablemente el total de reportes. Cuadro 8. Atributos en la Carga de las Páginas de P ruebas entre Testing y Producción

Atributo PPru PPro ToMiPru ToMiPro ToMaPru ToMaPro

Menú 2444 149902 88 3131 70982 298720

Cons Or 834 13727 75 1167 6567 256077

Cola Ins 22976 157556 2876 5981 35326 283954

TOTAL 3775 59906 18 39 70982 298720 Fuente: Informe Servidores Emcali. Jmeter. Julio 2012. Para terminar con la comparación se hace la diferencia entre los valores del promedio (P), el total de reportes mínimo (ToReMi) y el total de reportes máximo (ToReMa) de los atributos medidos de los servidores de Prueba y Producción. Es una operación matemática: ‘Prueba – Producción’, esto muestra los resultados obtenidos en las pruebas realizadas por cada uno de los usuarios de prueba, Ver cuadro 9. Cuadro 9. Diferencia de Atributos en la Carga de la s Páginas de Pruebas

85

Atributo P ToReMi ToReMa

Menú -147458 -3043 -227738

Cons Or -12893 -1092 -249510

Cola Ins -134580 -3105 -248628

TOTAL -56131 -21 -227738 Fuente: Informe Servidores Emcali. Jmeter. Julio 2012. Al comparar el promedio y los reportes mínimos y máximos, los valores dan negativos. Esto quiere decir que los reportes disminuyeron y se volvió más eficiente el servidor al momento de las consultas necesarias para seguir con el estado de los procesos.

11.4. PRUEBAS DE SINCRONIZACION DE DISCOS DE LOS CE NTROS DE DATOS

Las pruebas de sincronización consisten en verificar que la plataforma reconozca la información del Storage que por alguna eventualidad ha estado fuera de línea por un determinado tiempo. En el Anexo C se muestra el formato de pruebas implementado por el proveedor. Condiciones Iniciales. Antes de iniciar las pruebas las dos fibras oscuras están en operación normal. Los Mirrors solo tienen el LUN de su respectiva sede en los discos creados como se indica en el cuadro 10. Los discos tienen habilitados los mirros, estos son los discos de backup que tienen una sola LUN para probar la sincronización y conectividad de los dos centros de datos de Emcali. Cuadro 10. Pruebas de sincronización de discos de l os centro de datos de San Fernando

86

ID PRUEBA DESCRIPCION TIEM

Seg) PASO FALLO

1

Pruebas por

pérdida de Acceso a

LUN

En el Blade LIMO_T6340_00 crear un zpool de 10GB configurado en modo mirror un LUN de San Fernando y otro de Limonar. 0.3

X -

2

Pruebas por

perdida de conectivid

ad

En el BLADE LIMO_T6340_00 crear un zpool de 10GB configurado en modo mirror un LUN de San Fernando y otro de Limonar. 0.3

X -

3

Pruebas por

pérdida de Acceso a

LUN

En el Blade LIMO_T6340_01 crear un zpool de 10GB configurado en modo mirror un LUN de San Fernando y otro de Limonar. 0.4

X -

4

Pruebas por

perdida de conectivid

ad

En el BLADE LIMO_T6340_01 crear un zpool de 10GB configurado en modo mirror un LUN de San Fernando y otro de Limonar. 0.4

X -

5

Pruebas por

pérdida de Acceso a

LUN

En el Blade SAFE_T6340_00 crear un zpool de 10GB configurado en modo mirror un LUN de San Fernando y otro de Limonar. 0.3

X -

6

Pruebas por

perdida de conectivid

ad

En el BLADE SAFE_T6340_00 crear un zpool de 10GB configurado en modo mirror un LUN de San Fernando y otro de Limonar. 0.3

X -

7

Pruebas por

pérdida de Acceso a

LUN

En el Blade SAFE_T6340_01 crear un zpool de 10GB configurado en modo mirror un LUN de San Fernando y otro de Limonar 0.3

X -

8

Pruebas por

perdida de conectivid

En el BLADE SAFE_T6340_01 crear un zpool de 10GB configurado en modo mirror un LUN de 0.3

X -

87

ad San Fernando y otro de Limonar.

Fuente: Propia. González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012. • El Blade LIMO_T6340_00, es la tarjeta o Slot 1, del nodo de Limonar. • El Blade LIMO_T6340_01, es la tarjeta o Slot 2, del nodo de Limonar. • El Blade SAFE_T6340_00, es la tarjeta o Slot 1, del nodo de San

Fernando. • El Blade SAFE_T6340_01 es la tarjeta o Slot 2, del nodo de San

Fernando. Las pruebas fueron exitosas, los tiempos de sincronización no sobrepasaron de los 0.5 segundos entre las dos plataformas. Para no afectar a los usuarios e interrumpir servicio, el apagado y prendido de los switchs y toma de tiempos se ejecutaron a la madrugada. El único servicio que se afecto fue el DNS que por motivos de apagado quedo por fuera, sin embargo al normalizar los centros de datos, siguió con el funcionamiento normal.

12. PROCEDIMIENTOS DE OPERACIÓN Y MANTENIMIENTO

88

Los clientes, además de tener una opinión global sobre el servicio contratado, son capaces de juzgar sobre los componentes o atributos que tiene el producto adquirido. Los atributos de calidad son los componentes del servicio recibido, que el cliente valora de forma especial y puede percibir con claridad. La empresa prestadora del servicio debe investigar la satisfacción del usuario, que evalúa cada uno de los servicios. A través del levantamiento de la información de la satisfacción del usuario, se genera paquetes de servicios con valor agregado para así obtener la fidelización del cliente. La mejora continua de los servicios debe ser parte fundamental de la política de calidad y el direccionamiento estratégico de la empresa soportada por las directivas. A raíz de esto, fueron analizados los documentos existentes con el equipo de trabajo y se crean los procedimientos de Operación y Mantenimiento para la nueva plataforma que consta de actividades con respecto al área de control de telecomunicaciones. Los documentos contienen diagramas de flujo con la explicación del sistema de información e instructivos con los parámetros adecuados para el correcto funcionamiento. El formato de calidad de la empresa, se divide por procesos, subprocesos, actividades e instructivos, en el cuadro 11, está organizado de acuerdo a los parámetros y plantillas de calidad implementadas por Emcali Telecomunicaciones. Esta información se encontrará en los anexos debido a la cantidad de procesos que se realizaron y se puede extender sin limitación alguna se realiza la aclaración ya que este tema es de suma importancia para el proyecto. En al Anexo D, se encontraran los procesos que se aplicaron para la realización de este proyecto.

89

Cuadro 11. Catálogo de Procesos Implementados en lo s Centros de Datos de Emcali

EMPRESAS MUNICIPALES DE EMCALI EICE E.S.P. CATALOGO DE PROCESOS/SUBPROCESOS Y ACTIVIDADES

6 PROCESO OPERAR Y MANTENER TELECOMUNICACIONES

6030 SUBPROCESO OPERAR Y MANTENER EL SISTEMA DE CONTROL

603120 Actividad Elaborar Plan de Operación y Mantenimiento del Sist ema de Control. 120P01 Realizar la Planeación de la Operación y Mantenimiento de los Sistemas de Control 603121 Actividad Ejecutar la Operación y Mantenimiento del Sistema d e Control.

121P08 Verificar Operación AAA 121P08I001 Instructivo Verificar Peticiones del AAA 121P09 Verificar Operación BRAS 121P10 Monitorear y Gestionar Equipos de Datos e Internet 121P10I001 Instructivo Monitorear RMS y Nodo Internet 121P10I002 Instructivo Reparar Fallas Anomalía de los Datos e Internet 121P13 Administrar Servidores del Sistema de Telecomunicaciones 121P13I002 Instructivo Instructivo de Implementación de un Servicio en un Servidor 121P13I001 Instructivo Instructivo de Lineamiento de configuración de un Servidor 121P14 Gestionar Servidores del Sistema de Telecomunicaciones.

603122 Actividad Evaluar y Controlar la Operación y Mantenimiento de l Sistema de Control. 122P01 Evaluar y Controlar la Operación y Mantenimiento del Sistema de Control.

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012.

90

13. CONCLUSIONES Se logró reducir los tiempos finales de carga de los aplicativos sin afectar la calidad ni su funcionamiento. Esto, gracias a que se virtualizaron los diferentes dispositivos para cumplir en óptimas condiciones sus tareas. Gracias a las nuevas tecnologías implementadas por los fabricantes de dispositivos para la virtualización, las conexiones, las comunicaciones y la programación de los elementos que integran este proyecto se realizan fácilmente y esto se traduce en ahorro de tiempo y dinero. La arquitectura implementada en el centro de datos es funcional y aporta una serie de beneficios estratégicos dentro de la organización de Tecnologías de Información y Comunicaciones de Emcali, posee flexibilidad y capacidad de adoptar y adaptarse rápidamente a la necesidad eventual de incorporar nuevas tecnologías a futuro. Para poder administrar las necesidades y contribuir con el aprovisionamiento de las capacidades requeridas para dar cobertura, se crearon recursos basados en scripts para facilitar las labores del administrador de las plataformas. Las ventajas que se tiene es que son flexibles para modificar y buscar el mejor desempeño en la migración de los datos. Esta plataforma funciona de forma redundante en ambos centros para garantizar la continuidad de los servicios y la confiabilidad del producto de Internet Banda Ancha, con esto se garantiza que no habrá pérdida de información y se tendrá la seguridad que existe un Backup de la información para que en tal caso sea consultada y el servicio siga funcionando fluidamente. Se establecieron manuales de operación y mantenimiento los cuales, se deben leer con atención para realizar los procesos en cualquier ámbito donde existan las maquinas adquiridas por la empresa. De acuerdo a las observaciones realizadas en los procesos de migración cabe notar que la duración fue de días, a pesar que en la documentación se

91

analicen procesos cortos o de rápida acción, los factores externos toman un papel muy importante este tipo de procesos porque se correlacionan, por ejemplo, que las VLAN’s no estén conectadas, las fibras oscuras tengan algún tipo de interferencia, los switchs se apaguen o se reinicien, etc. Esto hace que se complique el proceso sin embargo los objetivos deben lograrse para no generar pérdidas a la empresa.

92

BIBLIOGRAFÍA ALBITZ, Paul. LIU, Cricket. DNS and Bind. O’Reilly. 2008. 70 Pág. AT&T Laboratories. Simple Mail Transfer Protocol. J. Klensin, Editor. Network Working Group. Abril 2001. 47 Pág. BRAVO, Yuri. Cableado Estructurado en un Data Center.Impress. Enero 2009. 41 Pág. CASTRO, Jorge. TRIMMIÑO, Ana María. RAMIREZ, Iván. MONTENEGRO, Mauricio. Cloud Computing-Una Perspectiva para Colombia. Mesa Sectorial. Versión 1.0.0.Abril 2010.63 Pág. DESAI, Milin. Oracle High Availability using Oracle VM with Sun Unified Storage. Sun Microsystem. 2010. 31 Pág. DHCP Server Configuration. F/X Communications.2007. 22 Pág. DUEÑAS QUESADA, Antonio Jesús. Tutorial Autentificación LDAP. Curso 2007. 60 Pág. Proyecto Integrador. Informática IES. GEDDES, Matthew. LDAP Directories.Augment-It. Mayo 2005. 51 Pág. HERNANDEZ PALMEROS, Karina. DATA CENTER. Trabajo de grado. Diciembre 2010. 144 Pág. INSTALACION Y ADMINISTRACION DEL MODULO DE SERVIDOR SUN BLADE T6340. Sun Microsystem, Inc. Oracle Corporation. Indiana USA. Diciembre 2008. 78 Pág. NETWORK TIME PROTOCOL. Hal Pomeranz and Deer Run Associates. Oakland CA. 2000. 33 Pág. PINILLOS QUINTERO, Fabián. RENGON RIOS, Andrés. Introduction to the Operations Support System (OSS). Revista Colombiana de Tecnologías Avanzadas. Volumen 2. Número 6. 2005. 6 Pág. POP/IMAP Email Engine.MarshallSoftCoputing, Inc. Versión 7.0. Huntsville USA. Octubre 2011. 31 Pág. PLAN DE PRUEBAS PARA SIMULACRO. Centro de Datos Alterno del Sistema de Información de Registro. SIR. Versión 1.3. Noviembre 2011. 11 Pág.

93

ANEXOS

Anexo A. PROCESOS DE CREACION DE LDOMS Y ZONAS SOLA RIS Se muestran los directorios y subdirectorios para la creación de las máquinas virtuales. Dentro del inventario de herramientas de administración para LDOMs tenemos los scripts:

• Lcreate • Ldestroy • Lbind • Lstart • Lstartall • Lbackup • Lresetconsole • Lrestart • Lservices • Lstop • Lstopall • Lcpu, • Lcpuall • Laddcpu • Laddmemory • Lremcpu • Lremmemory • Ltelnet • Lunbind • Lexport • Linfo • Llist.

Mientras que dentro del inventario de herramientas de administración para ZONAS tenemos los scripts:

• Zcreate

94

• Zdestroy • Zconfig • Zstart • Zrestart • Zstartall • Zstop • Zstopall • Zsetmemory • Zaddcpu • Zremcpu • Zbackup • Zconsole • Zcpuall • Zlist • Zattach • Zdetach • Zinstall • Zexport • Zinfo.

Cómo iniciar un LDOM después de ser creado en el BLADE. Figura 38. Arranque/inicio de LDOMs en Solaris

Fuente: Emcali Telecomunicaciones. Procesos Calidad. Erika González. 2012.

95

Figura 39. Detener LDOMs en Solaris

Fuente: Emcali Telecomunicaciones. Procesos Calidad. Erika González. 2012. Figura 40. Backup de LDOM

Fuente: Emcali Telecomunicaciones. Procesos Calidad. Erika González. 2012.

96

Cómo iniciar una ZONA después de ser creada en el LDOM. Figura 41. Arranque de Zonas en Solaris

Fuente: Emcali Telecomunicaciones. Procesos Calidad. Erika González. 2012. Figura 42. Detener una Zona en Solaris

Fuente: Emcali Telecomunicaciones. Procesos Calidad. Erika González. 2012.

97

Figura 43. Migración de Zonas en Solaris

Fuente: Emcali Telecomunicaciones. Procesos Calidad. Erika González. 2012.

98

Figura 44. Creación Zonas Solaris

Fuente: Emcali Telecomunicaciones. Procesos Calidad. Erika González. 2012.

99

Anexo B. DIAGRAMAS DE LOS CENTROS DE DATOS DE EMCAL I-TELECOMUNICACIONES

Conexiones Físicas de los Centro de Datos. Ver figura 45. Figura 45. Centro de datos de Emcali Telecomunicaci ones

Catalyst 2960

Sm art-UPS

1 5 0 0

AM ER IC A N P O WE R CO N VE R SIO N

Catalyst 2960

N etBotzUSB BSENSOR

L eak

Rope

Beac on LinkMonitor 550

4900

4900

SL500

PRIVATE PUBL IC RESERVED CLI 7410

STORAGE

STORAGE

7410

BROCATE 300

NEM 0

NEM 1

B

L

A

D

E

MGT _ 0

xgei _1/4xgei _1/3

1PCle 0

Link Out

Link Out

Link In

Lin

k In

MG T

MG T

T63

40

T63

40

X627

0

B9 B8 B7 B6 B5 B4 B3 B2 B1 B0

X62

70

X627

0

X62

70

BACK FRAME

1PCle 0

1PCle 1

2PCle 1

2PCle 0

1PCle 1

L ink Out

2P

Cle

12

PC

le 0

L ink In

T2000

Net 2

Net 3

SFP +1 SFP +2

SFP +1 SFP +2

fei_

0/1

Net 0

Net 1

fei_

0/2

4

fei_

0/10

fei_

0/8

fei_

0/6

fei_

0/4

fei_

0/2

(fe

i_0/

2)

(fei _0/4)

MG T

MG T

(fei _ 0/1)

fei_

0/2

4

fei_

0/5

fei_

0/7

fei_

0/9

fei_

0/2

3

fei_

0/3

(fei_ 0/3)

(fei _ 0/5)(fei _ 0/7)(fei _ 0/8)

(fei _0/6)(fei _ 0/9)(fei _ 0/10) Net 1

Net 0

Net 2

MG T

(fei

_0/

23)

MG T

(fei

_0/

24)

(gei

_0/

1)

2(xg

ei_

1/3)

1(xg

ei_

1/4)

2(xgei_1/4)

1(xgei_1/3)

1(gei_3/11)1(gei_3/12)

2(gei_3/12)

Ne

t_0

Ne

t_1

Ne

t_2

Net

_3

3/11

3/13

3/20

3/12

3/14

L ink In L ink Out

Net 3

xgei _1/5 xgei _1/6 xgei _1/7 xgei _1/8

(gei _0/8)

(gei _0/8)

PCIe_3 PCIe_ 4

1(xgei _1 /5) 2( xgei _1/6)

Link _0 Link _1

2(xgei _ 1/7)1(xgei _1/8)

Link _0 Link _ 1

Link _0 Link _1 Link _0 Link _ 1

2(xgei _ 1/5) 1(xgei _1 /6) 1( xgei _1/7 )2 (xgei _1/8 )

PCIe_ 3 PCIe_4

xgei _ 1/4xgei _1 /3 xgei _1/5 xgei _ 1/6 xgei _1/7 xgei _1/8

PCIe_5

PCIe_ 5

3/12

3/11

3/1

3

3/14

SAFE_6000_1

10. 29.110.30

10.29.110. 29

SAFE_T2000_1

SAFE_B300_1

SAFE_SL500_1

SAFE_2960_1SAFE_4900_1

SAFE_4900_2

SAFE_T160G_2

RS- XGS1- 2XGE -XFP

ZXR10 T160G ZTE

5

xgei _1/2xgei _1/1

xgei_5/1 xgei_5/2

xgei _1/ 2xgei _1/1

To-LIMO _4900_2_(xgei_1/1)

To-LIMO_4900_1_(xgei_1/1)

(gei

_0/2

)

3/20

gei

_0/

1ge

i_0/

2

USB 1

USB 2

APC1

2

fei_

0/1

2

USB 1

USB 2

UCS C 200M2Cisco

CAM_1 CAM _2

SENSOR D OOR RACK 2

1Control de Acceso(fei_0/12) ( fei_0/13)

fei_

0/1

4fe

i_0/

13

NetBotz

Adapter´s Power E thernet

CAM_1 CAM_2 CAM_3

(fei _0/15) ( fei_0/16) (fei_ 0/17)

APC

(fei _0/14)Infraestructor

Sensor Biometric 1

Sens or Biometric 2

2(gei_3/ 11)

4900

4900

7410

STORAGE

STORAGE

7410

xgei _1/ 4xgei _1/3

1PCle 0

Link Out

L ink Out

L ink In

Lin

k I

n

MG T

MG T

1PCle 01PCle 1

2PCle 12PCle 0

1PCle 1

L ink Out

2P

Cle

1

2P

Cle

0

L ink In

Net 2Net 3

Net 2

MG T

MG T

3/13

3/1

4

L ink In Link Out

Net 3

xgei _1 /5 xgei _ 1/6 xgei _1/7 xgei _1 /8

(gei_ 0/8)(gei _0/8)

PCIe_3 PCIe_4

1(xgei _1/5) 2(xgei _1/ 6)

Link _0 Link _1

2 (xgei _1/7 )1 (xgei _1 /8)

Link_0 Link _1

Link _0 Link _1 Link _ 0 Link _1

2(xgei _1/5) 1( xgei _1/6) 1(xgei _1/7) 2(xgei _ 1/8)

PCIe_3 PCIe_4

xgei _1/4xgei _1/3 xgei _1 /5 xgei _1/6 xgei _1 /7 xgei _1/ 8

PCIe_5

PCIe_5

3/13

3/1

4

xgei _1 /2

xgei _ 1/2xgei _1/ 1

xgei _1/ 1

RS -XGS 1-2XGE -XFP

ZXR10 T160G ZTE

5

NEM 0

NEM 1

B

L

A

D

E

MGT _0

T63

40

T63

40

X627

0

B9 B8 B7 B6 B5 B4 B3 B2 B1 B0

X62

70

X627

0

X62

70

BACK FRAME

SFP +1 SFP +2

SFP + 1 SFP + 2(fei _0/3)

2(xgei_1/3)1(xgei_1/4)

LIMO_6000 _1

10.29. 210.30

10.29.210.29

fei_

0/1

fei_

0/2

4

fei_

0/1

0fe

i_0/

8fe

i_0/

6fe

i_0/

4

fei_

0/2

fei_

0/24

fei_

0/5

fei_

0/7

fei_

0/9

fei_

0/2

3

fei_

0/3

gei_

0/1

gei

_0/2

fei_

0/12

fei_

0/14

fei_

0/1

3

( fei_0/24)

3 /20 (gei _0/ 2)

(fei

_0/2

3)

(ge

i_0/

1)3/

20

Net 0Net 1

(fei _0/5)(fei _ 0/7)(fei _0/8)

( fei _0/6)

( fei_ 0/9)( fei _0/10)

Net 0Net 1

xgei_5 /2xgei_5/1

2(xgei_1/4)1(xgei_1/3)

LIMO_4900_2

LIMO_4900_1

COLON _T160G_2

LIMO_2960_1

Controlled FileCopy authorized to:

CONECTION NETWORK DATA CENTER SAN FERNANDO Y LIMONAR

Design:David Blandón R . <dblandon @emcali.net .co>

UpDate:

Jose Ivan ValenciaThe content of this document is privileged and confidential of Emcali Telecommunications and is intended only to person or e ntity which is authorized without intending to be revealed , copied or disclosed to others .

To-SAFE_4900_2_(xgei_1/1)

To-SAFE_4900_1_(xgei_1/1)

x/ x Interface Origen (x/x) Interface Destino1(x/x) Switch SAFE_4900_12(x/x) Switch SAFE_4900_2

Index

Enlaces Ópticos 10Gbps

Fibra Oscura

Versión

22.06.04

( fei_0/11)

fei_

0/1

1

fei_

0/1

6fe

i_0/

15

fei_

0/17

fei_

0/1

8fe

i_0

/19

fei_

0/2

0fe

i_0/

21

Smart-UPS

1 5 0 0

A M ER IC AN P OW E R CO NV E RS IO N

UPS 2UPS 1

S mart-UPS

1 0 0 0

T estI

O

AMERI CAN PO WER CONVERSI ON

c

S mart-UPS

1 0 0 0

Te stI

O

AMERIC AN POW ER CONVERSI ON

AA 1 AA 2

(fei_ 0/19) (fei _0/18) (fei _ 0/21) (fei _ 0/20)

USB 1

USB 2

UCS C 200M2Cisco

Control de Acceso (fei _0/12)

USB 1

USB 2

APC1

2

(fei_ 0/13)Infraestructor

N etBotzUSB BSENSOR

Leak Rope

Beac on L inkMonitor 550

CAM _1 CAM_2

SENSOR D OOR

RACK 2

1

(fei _ 0/11)

Adapter´s Power Ethernet

CAM_1 CAM_2 CAM _3

( fei _0/15) (fei_ 0/16) (fei _0/17)

APC

( fei _0/14)

Sm art-UPS

1 5 0 0

A M ER IC AN P OW E R CO N VE RS IO N

Sm art-UPS

1 5 0 0

AM ER IC A N P O WE R CO N VE R SIO N

UPS 2UPS 1

S mart-UPS

1 0 0 0

Tes tI

O

A MERIC AN POW ER C ONVERSI ON

S mar t-UP S

1 0 0 0

Tes tI

O

AM ERICAN POW ER CO NVERSI ON

AA 1 AA 2

( fei_0/19) (fei_0/18) (fei _0/21) (fei _0/20)

fei_

0/1

6

fei_

0/11

fei_

0/2

0fe

i_0/

18

fei_

0/1

7fe

i_0/

15

fei_

0/2

1fe

i_0/

19

Sun Blade 6000

Cisco Catalyst 4900 Switch

Cisco Catalyst 4900 Switch

Cisco Catalyst 4900 Switch

Cisco Catalyst 4900 Switch

Sun Blade 6000

Storage LS500 Storage 7410

Storage 7410

Storage 7410

Storage 7410 Array J4400

Array J4400

Array J4400

Array J4400

Brocate 300

Sun Fire T2000

Cisco Catalyst 2960

ZTE T160 ZTE T160

Cisco Catalyst 2960

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012.

100

Conexión Física Centro de Datos San Fernando. Ver figura 46. Figura 46. Conexiones Físicas del Centro de datos d e San Fernando

Catalyst 2960

4900

4900

SL500

PRIVATE PUBLIC RESERVED CLI 7410

Controlled FileCopy authorized to:

CONECTION NETWORK DATA CENTER SAN FERNANDO

Design:David Blandón R . <dblandon @emcali.net.co>

UpDate:Jose Ivan Valencia

Version 12.03.26

The content of this document is privileged and conf idential of Emcali Telecommunications and is intend ed only to person or entity which is authorized withou t intending to be revealed, copied or disclosed to others.

STORAGE

STORAGE

7410BROCATE 300

NEM 0

NEM 1

BLADE

MGT _0

xgei _ 1/4xgei _1/ 3

1PCle 0

Link Out

Link Out

Link In

Link

In

MGT

MGT

T634

0

T634

0

X627

0B9 B8 B7 B6 B5 B4 B3 B2 B1 B0

X627

0

X627

0

X627

0

BACK FRAME

1PCle 01PCle 1

2PCle 12PCle 0

1 PCle 1

Link Out

2PCl

e 1

2PCl

e 0

Link In

T2000

Net 2

Net 3

SFP +1 SFP +2

SFP + 1 SFP + 2

fei_0

/1

Net 0Net 1

fei_0

/24

fei_0

/10fei

_0/8

fei_0

/6fei

_0/4

fei_0

/2(fe

i_0/2)

(fei_0/4)

MGT

MGT

(fei_0/1)

fei_0

/24

fei_0

/5fe

i_0/7

fei_0

/9

fei_0

/23

fei_0

/3

(fei_0/3)

(fei_0/5)(fei_0/7)(fei_0/8)

(fei_0/6)(fei_0/9)(fei_0/10) Net 1

Net 0

Net 2

MGT

(fei_

0/23)

MGT

(fei_0

/24)

(gei_

0/1)

2(xge

i_1/3)

1(xge

i_1/4)

2(xgei_1/4)

1(xgei_1/3)

1(gei_3/11)1(gei_3/12)

2(gei_3/12)

Net_0

Net_1

Net_2

Net_3

3/11

3/13 3/20

3/12

3/14

Link In Link Out

Net 3

xgei _1/5 xgei _1/6 xgei _1/ 7 xgei _1/8

(gei_0/8)

(gei_0/8)

PCIe_3 PCIe_4

1(xgei _1 /5) 2(xgei _ 1/6)

Link _0 Link _ 1

2(xgei _ 1/7) 1(xgei _ 1/8)

Link _0 Link _1

Link _0 Link _1 Link _0 Link _1

2(xgei _1 /5)1 (xgei _1/ 6) 1( xgei _1/7) 2( xgei _1/8 )

PCIe_3 PCIe_4

xgei _ 1/4xgei _1/ 3 xgei _1/5 xgei _1 /6 xgei _1/7 xgei _ 1/8

PCIe_ 5

PCIe_5

3/12 3/1

1

3/13

3/14

SAFE_6000_1

10.29.110.30

10.29.110.29

SAFE_T2000_1

SAFE_B300_1

SAFE_SL500_1

SAFE_2960_1

SAFE_4900_1

SAFE_4900_2

SAFE_T160G_2

RS -XGS 1-2XGE-X FP

ZXR10 T160G ZTE

5

xgei _1/2xgei _ 1/1

xgei_5/1 xgei_5/2

xgei _1/2xgei _ 1/1

To-LIMO_4900_2_(xgei_1/1)

To-LIMO_4900_1_(xgei_1/1)

QinQ Custumer

Ovlan 4082

x/x Interface Origen(x/x) Interface Destino

1(x/x) Switch SAFE _4900 _12(x/x) Switch SAFE _4900 _2

Index

Enlaces Ópticos 10Gbps

Fibra Oscura

(gei_0

/2)

3 /20

gei_0

/1ge

i_0/2

fei_0

/12

fei_0

/14fei

_0/13

2(gei_3/11)

Smart-UPS

1 5 0 0

AMERI CAN POW ER CO NVERSI ON

NetBotzUSB BSENSOR

Leak Rope

Beacon Link Monitor 550

USB 1

USB 2

APC1

2

USB 1

USB 2

UCS C200M2Cisco

CAM_1 CAM_2

SENSOR DOOR RACK 2

1Control de Acceso( fei _0/12) (fei _0/13)

NetBotz

Adapter´s P ower E thernet

CAM_1 CAM_ 2 CAM_3

(fei_0/15) (fei_0/16) (fei_0/17)

APC

(fei_0/14)Infraestructor

Sensor Biometr ic 1

Sensor Biometr ic 2

(fei _0/11)

Smart-UPS

1 5 0 0

AM ERICA N POW ER CONVE RSIO N

UPS 2UPS 1

Smart-UPS

1 0 0 0

TestI

O

AM ERICAN POWER CONVERSION

Smart-UPS

1 0 0 0

Tes tI

O

AMERICAN POWER CO NVERSION

AA 1 AA 2

(fei _0/19) ( fei _0/18) (fei _0/21) (fei _0/20)

fei_0

/15

fei_

0/17

fei_0

/19

fei_0

/21

fei_0

/16

fei_0

/18

fei_0

/20

fei

_0/11

Sun Blade 6000

Cisco Catalyst 4900 Switch

Cisco Catalyst 4900 Switch

Storage 7410

Storage 7410

Array J4400

Array J4400

ZTE T 160

Sun Fire T2000

Brocate 300

Storage LS500

Cisco Catalyst 2960

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012.

101

Conexión Física del Centro de Datos de Limonar. Ver figura 47. Figura 47. Conexiones Físicas del Centro de Datos d e Limonar

Catalyst 2960

NetBotzUSB BSENSOR

Leak Rope

Beacon LinkMonitor 550

4900

4900

7410

Controlled FileCopy authorized to:

CONECTION NETWORK DATA CENTER SAN FERNANDO

Design:David Blandón R . <dblandon @emcali.net.co>

UpDate:

Jose Ivan Valencia

Version 12.03.26

The content of this document is privileged and conf idential of Emcali Telecommunications and is inten ded only to person or entity which is authorized without intending to be revealed, copied or disclosed to ot hers.

STORAGE

STORAGE

7410

NEM 0

NEM 1

BLADE

MGT _0

xgei _1 /4xgei _1/3

1PCle 0

Link Out

Link Out

Link In

Link

In

MGT

MGT

T634

0

T634

0

X627

0

B9 B8 B7 B6 B5 B4 B3 B2 B1 B0

X627

0

X627

0

X627

0

BACK FRAME

1PCle 01PCle 1

2PCle 12PCle 0

1PCle 1

Link Out

2PCl

e 1

2PC

le 0

Link In

Net 2

Net 3

SFP +1 SFP + 2

SFP +1 SFP +2

fei_0

/1

Net 0

Net 1

fei_0

/24

fei_0

/10fei

_0/8

fei_0

/6fei

_0/4

fei_0

/2

fei_0

/24

fei_0

/5fei

_0/7

fei_0

/9

fei_0

/23

fei_0

/3

(fei_0/3)

(fei_0/5)(fei_0/7)(fei_0/8)

(fei_0/6)( fei_0/9)(fei_0/10) Net 1

Net 0

Net 2

MGT

(fei_0

/23)

MGT

(fei_0

/24)

(gei_

0/1)

2(xg

ei_1/3

)

1(xg

ei_1/4

)

2(xgei_1/4)

1(xgei_1/3)

3/13

3/20

3/14

Link In Link Out

Net 3

xgei _ 1/5 xgei _ 1/6 xgei _1/7 xgei _ 1/8

(gei_0/8)

(gei_0/ 8)

PCIe_ 3 PCIe_4

1( xgei _1/5 ) 2(xgei _1 /6)

Link _ 0 Link _1

2 (xgei _1/ 7) 1(xgei _1 /8)

Link _ 0 Link _1

Link _ 0 Link _ 1 Link _ 0 Link _1

2 (xgei _1/5 ) 1( xgei _1/6 ) 1(xgei _ 1/7) 2(xgei _ 1/8)

PCIe_3 PCIe_4

xgei _1/ 4xgei _1/3 xgei _1 /5 xgei _1/ 6 xgei _ 1/7 xgei _1 /8

PCIe_5

PCIe_5

3/13 3/14

LIMO_6000_1

10.29.210 .30

10.29.210.29

LIMO_2960_1

LIMO_4900_1

LIMO_4900_2

COLON_T160G_2

RS-X GS1-2XGE-XFP

ZXR10 T160G ZTE

5

xgei _1 /2

xgei_5/1 xgei_5/2

xgei _1/2xgei _1 /1

To-SAFE_4900_2_(xgei_1/1)

To-SAFE_4900_1_(xgei_1/1)

x/x Interface Origen (x/x) Interface Destino1(x/x) Switch SAFE _4900 _12(x/x) Switch SAFE _4900 _2

Index

Enlaces Ópticos 10Gbps

Fibra Oscura

(gei

_0/2

)

3/20

gei_0

/1ge

i_0/2

USB 1

USB 2

APC12

fei_0

/12

USB 1

USB 2

UCS C200M2Cisco

CAM_1 CAM_ 2

SENSOR DOOR RACK 2

1Control de Acceso(fei_0/?) (fei_0/?)

fei_0

/14fei

_0/13

NetBotz

Adapter´s Power Ethernet

CAM_ 1 CAM_2 CAM_3

(fei_0/15) (fei_0/16) ( fei_0/17)

APC

( fei_0/14)Infraestructor

Sensor Biometr ic 1

Sensor Biometr ic 2

xgei _1 /1

Cisco Catalyst 2960

Sun Blade 6000

Cisco Catalyst 4900 Switch

Cisco Catalyst 4900 Switch

ZTE T160

Array J4400

Array J4400

Storage 7410

Storage 7410

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012.

102

En los Centros de Datos de Emcali Telecomunicaciones, de las Conexiones VLAN’s para el tráfico de datos. A nivel de capa 2, se diferencian el tipo de tráfico que se implementó en los centros de datos de Emcali como se muestra en la siguiente cuadro 12. Cuadro 122. Índex de VLAN's

INDEX de VLAN's COLOR FIBRA TIPO DE TRAFICO Naranja 96 Servicios

Gris 104 Servicios Roja 100 Administración Principal

Morada 110 Administración Principal Amarillo 113 Storage

Azul 114 Administración Negro 112 No Instanciada

Aguamarina 115 No Instanciada

Verde 116 Backup y

Sincronización Fuente: Propia. González Caicedo, Erika Andrea. Emcali Telecomuniciones. 2012 Los gráficos que se mostrará a continuación, son la distribución de las VLAN en la red y se implementó el protocolo Spanning Tree para evitar Loops en ella.

103

Conexiones de las VLAN’s implementadas en los centros de datos de Emcali Telecomunicaciones. Ver figura 48. Figura 48. VLAN’s de los Centros de Datos de Emcali Telecomunicaciones

|Vlan 110 |

Catalyst 2960

4900

4900

SL500

PRIVATE PUBLIC RESERVED CLI

7410

7410

BROCATE 300

NEM 0

NEM 1

B

L

A

D

EMGT

MGT

T6

340

T63

40

X6

270

B9 B8 B7 B6 B5 B4 B3 B2 B1 B0

X62

70

X627

0

X6

270

BACK FRAME

T2000

SFP +1 SFP +2

SFP + 1 SFP +2

MGT

MGT

SAFE_6000_1

10.29.110 .30

10.29.110.29

SAFE_T2000_1

SAFE_B300_1

SAFE_SL500 _1

SAFE_2960_1SAFE_4900_1

SAFE_4900_2

SAFE_T160G_2

RS- XGS 1- 2XGE-XFP

ZXR10 T160G ZTE

5

4900

4900

7410

7410

MGT

MGT

MGT

RS- XGS1 -2XGE- XFP

ZXR10 T160 G ZTE

5

NEM 0

NEM 1

B

L

A

D

E

T6

34

0

T6

340

X627

0

B9 B8 B7 B6 B5 B4 B3 B2 B1 B0

X6

270

X62

70

X6

27

0

BACK FRAME

SFP +1 SFP +2

SFP +1 S FP +2

LIMO_6000 _1

10.29.210.30

10.29.210.29

Catalyst 2960

LIMO_4900_2

LIMO_4900_1

COLON_T160G_2

LIMO_ 2960_1

Controlled FileCopy authorized to:

CONECTION NETWORK DATA

CENTER SAN FERNANDO Y LIMONARDesign:

David Blandón R . <dblandon @emcali.net.co>

UpDate :Jose Ivan Valencia

The content of this document is privileged and confidential of Emcali Telecommunications and is intended only to person or e ntity which is authorized without intending to be revealed , copied or disclosed to others .

x/x Interface Origen (x/x) Interface Destino1(x/x) Switch SAFE_4900 _1

2(x/x) Switch SAFE_4900 _2

Index

Enlaces Ópticos 10Gbps

Fibra Oscura

Versión

12.05.03

Smart-UPS

1 5 0 0

A ME R ICA N P OW E R CO NV E RS IO N

NetBotzUSB BSENSOR

Leak

Rope

Beac on L inkMonitor 550

USB 1

USB 2

APC1

2

USB 1

USB 2

UCS C200M2Cisco

CAM _1 CAM_2

SENSOR D OOR

RACK 2

1

Control de Acceso (fei_0/12) (fei _0/13) NetBotz

Adapter´s Power Etherne t

CAM _1CAM_2 CAM_3

(fei _0/15) (fei _0/16) (fei _0/17)

APC

( fei_0/14)Infraestructor

Sens or

Biometric 1

Sensor

Biometric 2

(fei _0 /11)

Sm art-UPS

1 5 0 0

A M ER IC AN P OW E R CO N VE R SIO N

UPS 2UPS 1

Smar t-UP S

1 0 0 0

TestI

O

AMER ICAN POW ER CO NVERSI ON

Smart- UP S

1 0 0 0

T estI

O

AMERI CAN POWE R CO NVERSI ON

AA 1 AA 2

( fei_0/19) ( fei_0/18) ( fei _0/21) ( fei_0/20)

USB 1

USB 2

UCS C200M 2Cisco

Control de Acceso ( fei _0/12)

USB 1

USB 2

APC1

2

( fei _0/13)Infraestructor

NetBotzUSB BSENSOR

Leak

RopeBeacon Link

Monitor 550

CAM _1CAM_2

SENSOR D OOR

RACK 2

1

( fei _0/11)

Adapter´s P ower Ethernet

CAM_1 CAM _2 CAM _3

(fei _0/15) ( fei _0/16 ) (fei_0/17 )

APC

(fei _0/14)

Smart-UPS

1 5 0 0

A ME R IC AN P OW E R CO N VE RS IO N

Smart-UPS

1 5 0 0

A ME R IC AN P OW E R CO N VE RS IO N

UPS 2UPS 1

Smart- UPS

1 0 0 0

T estI

O

A MERI CAN POWE R CO NVERSI ON

Smart-UPS

1 0 0 0

Te stI

O

AM ERIC AN PO WER CONVER SION

AA 1 AA 2

(fei _0/19) (fei_0/18) (fei_0/21) (fei _0/20)

Sensor

Biometric 1

Sens or

Biometric 2

|Vlan 114 ||Vlan 116 |

|Vlan 100 |

|Vlan 110 |

|Vlan 113 |

|Vlan 114 |

|Vlan 110 ||Vlan 100 ||Vlan 115 |

|Vlan 96 ||Vlan 112 |

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012.

104

Protocolo de Spanning Tree, implementado en los centros de datos de Emcali. Ver figura 49. Figura 49. Spanning Tree de la Van 113 del Storage

4900

4900

7410

7410

NEM 0

NEM 1

B

L

A

D

EMGT

MGT

T63

40

T63

40

X62

70

B9 B8 B7 B6 B5 B4 B3 B2 B1 B0

X627

0

X6

270

X6

270

BACK FRAME

SFP +1 SFP +2

SFP +1 SFP +2

SAFE_6000_1

10.29.110 .30

10.29.110.29

SAFE _4900_1

SAFE_4900_2

To-LIMO _4900_2_(xgei_1/1)

To-LIMO_4900_1_(xgei_1/1)

4900

4900

7410

7410

MG T

MGT

MG T

NEM 0

NEM 1

B

L

A

D

E

T6

340

T63

40

X6

270

B9 B8 B7 B6 B5 B4 B3 B2 B1 B0

X62

70

X627

0

X6

270

BACK FRAME

SFP +1 SFP +2

SFP +1 SFP +2

LIMO_6000_1

10.29.210.30

10.29 .210.29

LIMO_4900_2

LIMO_4900_1

Controlled FileCopy authorized to:

CONECTION NETWORK DATA

CENTER SAN FERNANDO Y LIMONARDesign:

David Blandón R . <dblandon @emcali.net .co>

UpDate:Jose Ivan Valencia

The content of this document is privileged and confidential of Emcali Telecommunications and is intended only to person or e ntity which is authorized without intending to be revealed , copied or disclosed to others .

To-SAFE_4900_2_(xgei_1/1)

To-SAFE_4900_1_(xgei_1/1)

Versión

12.05.02

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012.

105

Spanning Tree de la VLANs 116 de Backup y Sincronización. Ver figura 50. Figura 50. Spanning Tree de la Van 113 del Storage

4900

4900

7410

7410

NEM 0

NEM 1

B

L

A

D

EMG T

MG T

T634

0

T634

0

X627

0

B9 B8 B7 B6 B5 B4 B3 B2 B1 B0

X62

70

X62

70

X627

0

BACK FRAME

SFP +1 SFP +2

SFP +1 SFP +2

SAFE_6000_1

10.29.110.30

10.29.110.29

SAFE _4900_1

SAFE_4900_2

To-LIMO_4900_2_(xgei_1/1)

To-LIMO_4900_1_(xgei_1/1)

4900

4900

7410

7410

MG T

MG T

MG T

NEM 0

NEM 1

B

L

A

D

E

T63

40

T634

0

X62

70

B9 B8 B7 B6 B5 B4 B3 B2 B1 B0

X627

0

X62

70

X62

70

BACK FRAME

SFP +1 SFP +2

SFP + 1 SFP +2

LIMO_6000_1

10.29.210.30

10.29.210 .29

LIMO_4900_2

LIMO_4900_1

Controlled FileCopy authorized to:

CONECTION NETWORK DATA CENTER SAN FERNANDO Y LIMONAR

Design:David Blandón R . <dblandon @emcali.net .co>

UpDate:

Jose Ivan ValenciaThe content of this document is privileged and confidential of Emcali Telecommunications and is intended only to person or e ntity which is authorized without intending to be revealed , copied or disclosed to others.

To-SAFE_4900_2_(xgei_1/1)

To-SAFE_4900_1_(xgei_1/1)

x/x Interface Origen (x/x) Interface Destino1(x/x) Switch SAFE_4900_12(x/x) Switch SAFE_4900_2

Index

Enlaces Ópticos 10 Gbps

Fibra Oscura

Versión

12.05.02

Fuente: González Caicedo, Erika Andrea. Emcali Telecomunicaciones. 2012.

106

Anexo C. PROTOCOLO DE PRUEBAS DE EMCALI-TELECOMUNIC ACIONES Las pruebas de sincronización consisten en verificar que la plataforma reconozca la información del Storage que por alguna eventualidad, ha estado fuera de línea por algún tiempo. Condiciones Iniciales: Antes de iniciar las pruebas, las dos fibras oscuras están en operación y los Mirror solo tienen el LUN de la respectiva sede anunciado en los discos creados. Pruebas por pérdida de Acceso a LUN En el Blade LIMO_T6340_00 crear un zpool de 10GB configurando en modo mirror un LUN de San Fernando y oro de Limonar. Ocupar 1GB de información con datos en el nuevo zpool creado Quitar el LUN de San Fernando que pertenece al mirror “zpooldetach”. Modificar la información del disco. Añadir de nuevo el LUN de San Fernando “zpoolatach” Revisar que el zpool sincroniza la información y los datos no se corrompen. Pasa _X___ Falla____

107

Pruebas por perdida de conectividad En el BLADE LIMO_T6340_00 crear un zpool de 10GB configurando en modo mirror un LUN de San Fernando y otro de Limonar. Ocupar 1GB de información con datos en el nuevo zpool creado Bajar las interfaces que conectan a las fibras oscuras desde los Switch de Limonar. Modificar la información del disco Subir las interfaces que conectan a las fibras oscuras desde los Switch de Limonar. Revisar que el zpool sincroniza la información y los datos no se corrompen. Pasa __X__ Falla____ Pruebas por pérdida de Acceso a LUN En el Blade LIMO_T6340_01 crear un zpool de 10GB configurando en modo mirror un LUN de San Fernando y oro de Limonar. Ocupar 1GB de información con datos en el nuevo zpool creado Quitar el LUN de San Fernando que pertenece al mirror “zpooldetach”. Modificar la información del disco Añadir de nuevo el LUN de San Fernando “zpoolatach” Revisar que el zpool sincroniza la información y los datos no se corrompen.

108

Pasa _X___ Falla____ Pruebas por perdida de conectividad En el BLADE LIMO_T6340_01 crear un zpool de 10GB configurando en modo mirror un LUN de San Fernando y otro de Limonar. Ocupar 1GB de información con datos en el nuevo zpool creado Bajar las interfaces que conectan a las fibras oscuras desde los Switch de Limonar. Modificar la información del disco Subir las interfaces que conectan a las fibras oscuras desde los Switch de Limonar. Revisar que el zpool sincroniza la información y los datos no se corrompen. Pasa __X__ Falla____ Pruebas por pérdida de Acceso a LUN En el Blade SAFE_T6340_00 crear un zpool de 10GB configurando en modo mirror un LUN de San Fernando y oro de Limonar. Ocupar 1GB de información con datos en el nuevo zpool creado Quitar el LUN de San Fernando que pertenece al mirror “zpooldetach”. Modificar la información del disco

109

Añadir de nuevo el LUN de San Fernando “zpoolatach” Revisar que el zpool sincroniza la información y los datos no se corrompen. Pasa __X__ Falla____ Pruebas por perdida de conectividad En el BLADE SAFE_T6340_00 crear un zpool de 10GB configurando en modo mirror un LUN de San Fernando y otro de Limonar. Ocupar 1GB de información con datos en el nuevo zpool creado Bajar las interfaces que conectan a las fibras oscuras desde los Switch de Limonar. Modificar la información del disco Subir las interfaces que conectan a las fibras oscuras desde los Switch de Limonar. Revisar que el zpool sincroniza la información y los datos no se corrompen. Pasa ___X Falla____ Pruebas por pérdida de Acceso a LUN En el Blade SAFE_T6340_01 crear un zpool de 10GB configurando en modo mirror un LUN de San Fernando y oro de Limonar. Ocupar 1GB de información con datos en el nuevo zpool creado

110

Quitar el LUN de San Fernando que pertenece al mirror “zpooldetach”. Modificar la información del disco. Añadir de nuevo el LUN de San Fernando “zpoolatach” Revisar que el zpool sincroniza la información y los datos no se corrompen. Pasa __X__ Falla____ Pruebas por perdida de conectividad En el BLADE SAFE_T6340_01 crear un zpool de 10GB configurando en modo mirror un LUN de San Fernando y otro de Limonar. Ocupar 1GB de información con datos en el nuevo zpool creado Bajar las interfaces que conectan a las fibras oscuras desde los Switch de Limonar. Modificar la información del disco Subir las interfaces que conectan a las fibras oscuras desde los Switch de Limonar. Revisar que el zpool sincroniza la información y los datos no se corrompen. Pasa ___X_ Falla____ NOTA: PRUEBAS EXITOSAS CON TIEMPO DE SINCRONIZACION ADECUADO PARA LA TRANSMISION DE TRAFICO DE DATOS, PROTOCOLO DE PRUEBAS REALIZADAS POR:EMCALI TELECOMUNICACIONES, I NFOMEDIA S. A.

111

Anexo D. PROCEDIMIENTOS DE OPERACIÓN Y MANTENIMIEN TO.

INSTRUCTIVO VERIFICACION DE PETICIONES AAA�

CODIGO: 121P08I001 VERSION: 2.0 FECHA: 2012/08/28

Página 1 de �

1. OBJETIVO

Interpretar y validar las peticiones AAA que se observan en las pantallas de monitoreo.

2. ALCANCE

Inicia cuando se genera una anomalía en el comportamiento del AAA (autorizar y finaliza cuando se analizaron e interpretaron los datos de la situación.

3. IDENTIFICACION DE LA ACTIVIDAD �

PROCESO SUBPROCESO ACTIVIDAD PROCEDIMIENTO

Operar y mantener telecomunicaciones

Operar y Mantener el sistema de

Control

Ejecutar la operación y mantenimiento del sistema de control

Verificar operación AAA

Fuente: Modelo de Operación por Procesos EMCALI EICE ESP.

4. DEFINICIONES

AAA: Servicio de control de usuarios cuya función es autenticar, autorizar y acreditar cada petición. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

AUTENTICACIÓN: Proceso por el cual se comprueba identidad de usuario, la cual se consigue mediante la presentación de una propuesta de identidad (nombre usuario) y la demostración de estar en posesión de las credenciales que permiten comprobar contraseña. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

AUTORIZACIÓN: Consecución de privilegios específicos (incluido ninguno) a un usuario basándose en su identificación (autenticado), en los privilegios solicitados y en el estado actual del sistema. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

B-RAS: Equipo de control de usuarios y aguegador se sesiones (terminar sesión PPPoE). (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

INSTRUCTIVO VERIFICACION DE PETICIONES AAA�

CODIGO: 121P08I001 VERSION: 2.0 FECHA: 2012/08/28

Página 2 de �

CANAL INTERNACIONAL: Proveedor o carrier externo que se intercomunica con el núcleo de Internet. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

CONFIGURACIÓN: Secuencia establecida de comandos para realizar algún tipo de actividad. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

CORRECTIVO: Realizar cambio con el fin de alinear el funcionamiento, al objetivo de desempeño. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

CUANTIFICACIÓN: Del ingles Accounting; se refiere al seguimiento del consumo de los recursos de red por los usuarios. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

EVENTO: Es un suceso que afecta la operación de un servicio o un área con efectos de la no prestación de una actividad. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

FALLA EN LA RED: Anomalía dentro de las interconexiones, servicios, equipos o servidores de la empresa. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

GESTIONAR: Dirigir y controlar el funcionamiento de un sistema. (Fuentes: NTC ISO 9000:2000).

INTERCONEXIÓN: Es la vinculación de recursos físicos y soportes lógicos, incluidas las instalaciones esenciales necesarias, para permitir el interfuncionamiento de las redes y la interoperabilidad de servicios de telecomunicaciones. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

INTERFUNCIONAMIENTO DE LAS REDES: Es el correcto funcionamiento de dos redes interconectadas. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

INSTRUCTIVO VERIFICACION DE PETICIONES AAA�

CODIGO: 121P08I001 VERSION: 2.0 FECHA: 2012/08/28

Página 3 de �

INTEROPERABILIDAD DE LOS SERVICIOS: Es el correcto funcionamiento de los servicios que se prestan sobre dos redes interconectadas. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

ISP (INTERNET SERVICE PROVIDER) O NODO DE INTERNET: Es un área funcional que se encarga de ejercer el control de acceso a internet a los usuarios de EMCALI. (El concepto en EMCALI es diferente al exterior). (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

MASIVO: Falla parcial o total de un grupo de usuarios. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

MONITOREAR (SERVIDORES DE CONTROL): Realizar seguimiento visual de una interfaz que representa la operación de un servidor en tiempo real. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

MONITOREO (SERVIDORES DE CONTROL): Verificación de una serie de variables criticas que corren en un sistema operativo, para ejercer un control sobre el servidor. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

NIVEL DE TRÁFICO: Volumen de ocupación de un canal. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

PROVEEDOR: Entidad que suministra productos y/o servicios a una organización. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

RED: Elementos de interconexión que permiten prestar servicios a un conjunto de usuarios. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

REGISTRO: Documento que presenta resultados obtenidos o proporciona evidencia de actividades desempeñadas. (Fuentes: NTC ISO 9000:2000).

SERVIDOR: Es un tipo de Hardware, el cual permite compartir recursos físicos y lógicos en una red de área local. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

INSTRUCTIVO VERIFICACION DE PETICIONES AAA�

CODIGO: 121P08I001 VERSION: 2.0 FECHA: 2012/08/28

Página 4 de �

SISTEMA OPERATIVO: Es una secuencia de código que genera un programa de operación en el cual maneja un interfaz humano-máquina para una actividad o fin determinado. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

TICKET: Es un reporte consolidado que especifica un evento, donde detalla: número de ticket, descripción y fecha del evento. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

RFC: Request mor comment, Documentos producidos por la IETF (Internet Engineering Task Force) que contienen especificaciones técnicas y políticas sobre internet.

5. GENERALIDADES

El protocolo Radius es usado para llevar la información de autenticación, autorización y “accounting” entre un servidor de acceso Remoto (NAS) y un servidor AAA compartido.

En los RFC 2865 y RFC 2866, se describe la trama, los tipos de paquetes y los atributos usados por el protocolo. En el RFC 2869 se describen atributos adicionales para llevar información de autenticación, autorización y contabilización.

El protocolo radius tiene las siguientes características.

• Modelo Cliente / Servidor • Seguridad en la Red (Shared Secret) • Protocolo expandible (Atributos) • Puede funcionar en modo Proxy • Protocolo UDP • Autorización y autenticación (puerto UDP 1812) • Contabilización (Puerto 1813)

RADIUS maneja diferentes tipos de paquetes, estos son detallados a continuación:

� Access-Request: Estos son los paquetes enviados al servidor RADIUS, transportando la información usada para determinar si el usuario tiene permiso en un NAS específico.

� Access-Accept: Estos son los paquetes enviados por el servidor RADIUS, proporciona la información específica necesaria para que el usuario inicie el servicio.

INSTRUCTIVO VERIFICACION DE PETICIONES AAA�

CODIGO: 121P08I001 VERSION: 2.0 FECHA: 2012/08/28

Página 5 de �

� Access-Reject: Si algún valor de los atributos recibidos no es aceptable, password errado. vlan errada, puerto errado, entonces el servidor RADIUS debe responder con un Access- Reject.

Accounting-Request: Estos son los paquetes enviados al servidor RADIUS y contiene la información usada para realizar el contabilización del servicio proporcionado al usuario.

Accounting-Response: Estos son los paquetes enviados por el servidor RADIUS al cliente confirmando que el Accounting-Request fue recibido y guardado satisfactoriamente.

Access-Challenge: Estos son los paquetes enviados por el servidor radius cuando se hace una autenticación con Challenge. Cuando estos paquetes son recibidos el campo compara el campo Identifier con Access-Request pendiente

Interpretación estadística:

Los servidores RADIUS generan estadísticas de comportamiento cada 6 segundos, en donde se indica la cantidad de peticiones que llegan (Access-Request, Accounting-Request ) y la respuesta que se genero a cada uno de estas.

Figura 1: Estadísticas AAA

INSTRUCTIVO VERIFICACION DE PETICIONES AAA�

CODIGO: 121P08I001 VERSION: 2.0 FECHA: 2012/08/28

Página 6 de �

En la figura 1 se observan las estadísticas generadas por el servidor radius en donde el 100% corresponde a los mensajes tipo request, para los cuales se genera una respuesta en mensajes tipo Accept, Challenges, Reject, Dropped, Duplicated, Invalid, Bad Auth, Unknow o Malformed.

Se debe prestar especial atención a los paquetes Dropped, Duplicate, Invalid, Unknow y Malformed, debido a que estos indican un comportamiento no deseado del sistema, a continuación se describe el significado de este tipo de paquetes:

Dropped: Son paquetes descartados, generalmente son peticiones duplicadas o con mucho tiempo en cola.

Duplicated: el servidor puede detectar un duplicated request si la petición tiene el mismo cliente, el mismo puerto fuente y el mismo identificador en un periodo muy corto de tiempo. (Peticion del mismo usuario)

• Invalid: Paquetes detectados por el servidor AAA como inválidos. • Unknow: Paquetes detectados por el servidor AAA como desconocidos. • Malformed: Paquetes detectados por el servidor como malformados.

6. DESCRIPCIÓN

6.1. EQUIPO Y HERRAMIENTA UTILIZADOS

� Software Navis Radius

� Computador

� Putty

� Conectividad AAA

6.2. NORMAS DE SEGURIDAD

No aplica

INSTRUCTIVO VERIFICACION DE PETICIONES AAA�

CODIGO: 121P08I001 VERSION: 2.0 FECHA: 2012/08/28

Página 7 de �

6.3. INSTRUCCION

PASO TAREA DESCRIPCION

1 Verificar peticiones Se debe verificar el estado de las peticiones en las pantallas de gestión

2 Analizar peticiones Con base a las generalidades se debe realizar un análisis de la situación de las peticiones en el momento del evento

3 Diagnosticar peticiones Con base a la situación y el análisis posterior se debe diagnosticar la situación actual con referente al AAA

7. DOCUMENTOS RELACIONADOS

7.1 DOCUMENTOS INTERNOS

Ninguno

7.2 REGISTROS

Ninguno

7.3 DOCUMENTOS EXTERNOS

Request For Comments (RFC)

INSTRUCTIVO VERIFICACION DE PETICIONES AAA�

CODIGO: 121P08I001 VERSION: 2.0 FECHA: 2012/08/28

Página 8 de �

8. OBSERVACIONES

Participaron en la realización del procedimiento:

9. ANEXOS

No aplica.

Elaborado por:

Erika González

Cargo:

Pasante.

Fecha:

2012/08/28

Firma

Revisado por:

David Blandón

Cargo:

Ingeniero de Conmutación

Fecha:

2012/08/28

Firma

Aprobado por:

Jorge Martínez

Cargo:

Director de Ingeniería

Fecha:

2012/08/28

Firma

INSTRUCTIVO REPARAR FALLA O ANOMALIA EN DATOS E INTERNET

CODIGO: 121P10I002 VERSION: 2.0 FECHA: 2012/08/24

Página 1 de 12

1. OBJETIVO

Gestionar alarmas, fallas y ticket en los diferentes equipos que componen la RMS y nodo de Internet que influyen directamente en los servicios de datos e Internet de EMCALI E.I.C.E.- E.S.P

2. ALCANCE

El procedimiento inicia con la verificación de fallas o anomalías reportadas por teléfono, correo, ticket y finaliza cuando se soluciona las fallas o anomalías y se reporta en la bitácora para su posterior solución indicando el tipo de solución, tiempo o si esta pendiente por solución

3. IDENTIFICACION DE LA ACTIVIDAD

PROCESO SUBPROCESO ACTIVIDAD PROCEDIMIENTO

Operar y mantener telecomunicaciones

Operar y Mantener el sistema de control

Ejecutar la operación y

mantenimiento del sistema de control

Monitorear Y Gestionar Equipos

De La Red De Datos E Internet

Fuente: Modelo de Operación por Procesos de EMCALI EICE ESP.

4. DEFINICIONES �

4.1. MONITOREAR (SERVIDORES DE CONTROL)

Realizar seguimiento visual de la interfaz que representa la operación de un servidor en tiempo real. (Fuente Departamento Multiservicios, Área funcional Administración Departamento)

4.2. GESTIONAR (REPORTES DE FALLA) �

Tramitar la reparación de los reportes de fallas efectuando las tareas pertinentes para tal fin ya sea mediante enrutamiento o efectuando el cierre de los mismos. (Fuente: Departamento Atención y Soporte al servicio, Área funcional Diagnostico y Pruebas)

INSTRUCTIVO REPARAR FALLA O ANOMALIA EN DATOS E INTERNET

CODIGO: 121P10I002 VERSION: 2.0 FECHA: 2012/08/24

Página 2 de 12

4.3. TICKET �

Es un reporte consolidado que especifica un evento, donde se detalla: número de ticket, descripción y fecha del evento. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

4.4. NODO DE INTERNET �

Es un área funcional que se encarga de ejercer el control de acceso a Internet a los usuarios de EMCALI. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

4.5. BITÁCORA �

Documento que lleva en un procesador de palabras cuyo fin es registrar todas las novedad o información general de un turno.

5. GENERALIDADES

� La tabla de atención de fallas comunes solo se utiliza cuando no existe problemas masivos en la red.

� Antes de atender una falla se debe cerciorar de que no existen fallas masivas. � Todas las fallas puntuales del los usuarios debe ser registradas por el sistema de

ticket.

6. DESCRIPCIÓN

6.1. EQUIPO Y HERRAMIENTA UTILIZADOS �

� Acceso a la aplicación Infra de APC (UPS, sistema de aire acondicionado) (Dirección IP 10.29.10.84).

� Acceso a la aplicación gestión Cacti con perfil de turno (Dirección IP 10.29.10.71 | Cacti).

� Acceso a la aplicación NETNUMEN perfil de turno. � Acceso Sistema de Gestión ADSL con perfil de turno. � Acceso al aplicativo Ticket con perfil de turno. � Acceso al aplicativo gestión válida.

INSTRUCTIVO REPARAR FALLA O ANOMALIA EN DATOS E INTERNET

CODIGO: 121P10I002 VERSION: 2.0 FECHA: 2012/08/24

Página 3 de 12

� Acceso al Servicio VNC de monitoreo con perfil de turno (Dirección IP 10.29.10.126:9 | VLAN Gestión)

� Lista de contactos de soporte (Gestión Cacti – Contactos) � Cuenta de correo electrónico asociado al alias de [email protected]� Lista telefónica del personal de ronda

NORMAS DE SEGURIDAD

No aplica

6.2. INSTRUCCION

Ver anexos

7. DOCUMENTOS RELACIONADOS �

• Monitorear y Gestionar equipos de datos e Internet 125P11I001

7.1. DOCUMENTOS INTERNOS �

• Ninguno

7.2. REGISTROS �

• Ninguno

7.3. DOCUMENTOS EXTERNOS �

• Ninguno

8. ANEXOS

Anexo 1. Tabla de fallas

9. OBSERVACIONES �

INSTRUCTIVO REPARAR FALLA O ANOMALIA EN DATOS E INTERNET

CODIGO: 121P10I002 VERSION: 2.0 FECHA: 2012/08/24

Página 4 de 12

En la elaboración del procedimiento participaron

Elaborado por:

Erika González

Cargo:

Pasante

Fecha:

2012/08/24

Firma:

Revisado por:

David Blandón

Cargo:

Ingeniero de Conmutación

Fecha:

2012/08/24

Firma

Aprobado por:

Jorge Martínez

Cargo:

Director de Ingeniería

Fecha:

2012/08/24

Firma

INSTRUCTIVO REPARAR FALLA O ANOMALIA EN DATOS E INTERNET

CODIGO: 121P10I002 VERSION: 2.0 FECHA: 2012/08/24

Página 5 de 12

. ANEXO I:

TABLA DE FALLAS DE DATOS E INTERNET FALLA DIAGNOSTICO CAUSA SOLUCIÓN

Autenticación fallida – error 691

- El usuario no navega error 691 en bridge -Por lo general el usuario es IP fija

- Login o password mal configurado -Puerto mal configurado - Otro usuario tiene el login del cliente

- Verificar la comprobación del login y password ya sea por soporte o por Bras -Verificar VLAN del cliente o si esta en puerto según gestión ADSL - Cambiar clave de usuario y clarear la conexión existente

Autenticación fallida – error 678

- El usuario no navega error 678

-Problema en línea -Problema a nivel local con el usuario (cable telefónico o Ethernet) -Problema de configuración en el usuario (VPI y VCI) -Problema con el CPE -Problema puerto y/o tarjeta -Problema de configuración de VLAN

-Verificar estrado de transmisión de línea por netnumen - Verificar conexiones del computador y modem -Verificar configuración del modem -Descartar funcionamiento del CPE - Verificar si los puertos esta transmitiendo o en su defecto el puerto - Realizar seguimiento de VLAN hasta el BRAS

Lentitud en navegación

- El usuario presenta lentitud en su navegación

-El usuario tiene problemas en su computador -El usuario tiene problemas de línea telefónica. -El puerto tiene un profile menor a la velocidad contratada -El usuario se conecta erróneamente

- Descartar problemas en el computador del usuario - Verificar problemas de configuración de línea -Verificar el profile del cliente y configurar según la velocidad -Verificar que el usuario se conecte por el puerto que tiene el sistema - Verificar que el usuario

INSTRUCTIVO REPARAR FALLA O ANOMALIA EN DATOS E INTERNET

CODIGO: 121P10I002 VERSION: 2.0 FECHA: 2012/08/24

Página 6 de 12

se autentica correctamente en el BRAS

Inconvenientes en la navegación general

- perdida de paquetes hacia las paginas -Lentitud para cargar paginas

- Problemas de enrutamiento con los carrier - Alto procesamiento en los DNS

Reportar inmediatamente el caso al coordinador de la red o el ingeniero de ronda

Los usuarios no entra a una pagina especifica

Los usuarios no pueden entrar a una pagina especifica

- El sitio Web esta censurado - El sitio esta bloqueado por dirección - El sitio caduco su hosting

- Verificar si la pagina esta en las listas negras. -Confirmar que el dominio se resuelve en los DNS locales. -Confirmar enrutamiento hacia la IP de la página. - Verificar si el sitio tiene alguna restricción en el enrutamiento interno - Verificar fecha de inicio y terminación de hosting -Reportar al ingeniero de turno.

Correo El usuario no puede enviar correo desde un programa cliente (Outlook, thunderbird, entre otros)

- Programas cliente mal configurados - El usuario utiliza puerto no convencionales

- Verificación de configuración de programa - Pasar caso a ingeniero encargado del correo

Problema de suministro de energía

Ausencia de suministro de energía en el nodo

- No entran las fases de suministro de energía - No entran el suministro de energía de las plantas de emergencia - No entra suministro de energía de los inversores

Reportar inmediatamente el caso al personal de mantenimiento electromecánico

Problema de Temperatura

La temperatura del nodo de Internet esta por fuera de los umbrales

- La temperatura del nodo esta por encima del umbral (>23 °C) - La temperatura del nodo esta por debajo del

Reportar inmediatamente el caso al personal de mantenimiento electromecánico

INSTRUCTIVO REPARAR FALLA O ANOMALIA EN DATOS E INTERNET

CODIGO: 121P10I002 VERSION: 2.0 FECHA: 2012/08/24

Página 7 de 12

umbral (<10 °C) Loop - Caída abrupta

del trafico de Internet - Caída de petición de autenticación en los AAA - Saturación de interfaces en los anillos

- Caída masiva de navegación en los clientes - Fallas de autenticación masivas en los clientes - Utilización de interfaces en mas 95% dentro de los switches de un anillo

Reportar inmediatamente el caso al coordinador de la red o el ingeniero de ronda

Anomalías de trafico en canales internacionales

- Disminución repentina del trafico del canal internacional -Aumento repentino del trafico del canal internacional

- Problema de enrutamiento con el Carrier - Balanceo del trafico por caída de un enlace del canal internacional

Disminución repentina del trafico del canal internacional

Anomalías en los sistemas de autenticación

Graficación anómala en los sistemas de autenticación

- Disminución de peticiones “request” / segundo - Aumento en las peticiones “reject” / segundo - Aumento en las peticiones “Dropped” / segundo

Reportar inmediatamente el caso al coordinador de la red o el ingeniero de ronda

Anomalías en los enlaces de la red multiservicios

Graficación anómala de trafico en los enlaces de la red multiservicios

- Aumento repentino de tráfico en algún enlace de la red multiservicio. - Disminución repentina de tráfico en algún enlace de la red multiservicio. - Ausencia repentina de tráfico en algún enlace de la red multiservicio.

Reportar inmediatamente el caso al coordinador de la red o el ingeniero de ronda

Alarmas (físicas) en servidores

Visualización física del Led ámbar en los servidores

- Problema interno en el funcionamiento del servidor

Reportar inmediatamente el caso al coordinador de la red o el ingeniero de ronda

Ausencia de Graficación - Problema interno en el Reportar

INSTRUCTIVO REPARAR FALLA O ANOMALIA EN DATOS E INTERNET

CODIGO: 121P10I002 VERSION: 2.0 FECHA: 2012/08/24

Página 8 de 12

trafico en servidores

anómala en los enlaces de trafico de los servidores

funcionamiento del servidor - Problema interconexión del servidor con la red del nodo

inmediatamente el caso al coordinador de la red o el ingeniero de ronda

La disponibilidad de IP en BRAS es menor de 20 IP

Al verificar las IP en los BRAS están menor de 20 recursos libres

- El pool de IP’s disponibles para suministrar en la autenticación de los usuarios esta en estado critico de aprovisionamiento

Reportar inmediatamente el caso al coordinador de la red o el ingeniero de ronda para provisionar manualmente las IP en los BRAS

Desincronización de registros en LDAP’s

Al verificar las registros en los LDAP maestro y esclavo supera el 0.25% de desfase en los registros

Los servidores dejaron de sincronizar

Reportar inmediatamente para iniciar sincronización manual en los servidores LDPAP

La configuración de las interfaces en los T.160 y BRAS para MAC y VLAN no es la planeada

Al comparar la configuración original con la actual no es la misma

Modificación de la configuración del equipo no oficial

Reportar inmediatamente el caso al coordinador de la red o el ingeniero de ronda para configurar según plan original

INSTRUCTIVO REPARAR FALLA O ANOMALIA EN DATOS E INTERNET

CODIGO: 121P10I002 VERSION: 2.0 FECHA: 2012/08/24

Página 9 de 12

ANEXO 2

MANTENIMIENTO CORRECTIVO SERVIDORES RADIUS

• En las pantallas de monitoreo del nodo de internet se observa la interface gráfica de cada uno de los tres servidores Radius:

10.29.114.197 � Autenticación Master

10.29.114.222 � Autenticación Slave

10.29.114.235 � Autenticación Slave

• Inicialmente se analiza la información del evento reportado por el personal de turno para determinar sobre que servidor actuar y la posible solución del evento.

• El administrador de nodo o el webmaster verifica el estado de los servicios

- Cantidad de memoria consumida en el servidor - Porcentaje de procesamiento - Conectividad

1. VERIFICACION LINEA DE COMANDOS (consola)

1.1 La memoria y el procesamiento se verifica entrando remotamente por ssh o entrando directamente en la consola solaris del servidor y utilizando el comando: “prstat”

Este informa la cantidad de memoria, cpu consumida y disponible, si esta con valores mayores a los umbrales definidos se debe analizar los log que son los que indican cual es el proceso causante del alto consumo de recursos. Y verificar si es necesario reiniciar el servicio.

Umbrales:

Memoria > 3000Kilobaytes libres

Swap > 300Megas libre

Normalmente el proceso que más consume memoria es el proceso java

INSTRUCTIVO REPARAR FALLA O ANOMALIA EN DATOS E INTERNET

CODIGO: 121P10I002 VERSION: 2.0 FECHA: 2012/08/24

Página 10 de 12

Procesamiento

porcentaje libre de cpu > 60.0%id

1.2 Verificación de Espacio en disco

Utilizar el comando “df –k” y comprobar que el raíz (/) no este a el 100% de utilización umbral

El raíz / uso% < 85%

El alto consumo de espacio generalmente lo generan los log y estos no se deben borrar. Se deben comprimir y pasar por medio de ftp al servidor con el repositorio de archivos de backup

El directorio donde están los archivos de log es:

Archivos de Autenticacion,

data/radiusaccounting/logSAFE-T6340/SAFE-T6340-000/autenticacion_master_a/LPDR/10.29.111.20/bras.

Archivos de Accounting

data/radiusaccounting/logSAFE-T6340/SAFE-T6340-000/accounting_master_a/LPDR/10.29.111.20/bras

1.3 Verificar estado del servicio de radius:

101 Server active

NavisRadius Radius Server: responding

101 Server up

NavisRadius Configuration Server: responding

INSTRUCTIVO REPARAR FALLA O ANOMALIA EN DATOS E INTERNET

CODIGO: 121P10I002 VERSION: 2.0 FECHA: 2012/08/24

Página 11 de 12

1.4 Servicio de monitoreo Grafico Remoto por VNC

Para la entrada remota a la interfaz grafica del radius debe estar activo el servicio VNC

/etc/init.d/vncserver status verificación

Parar el servicio

/etc/init.d/vncserver stop

Iniciar el servició

/etc/init.d/vncserver start

• Se verifica que haya quedado activa la aplicación.

1.5 Verificación de conectividad

La conectividad principal con los servidores de LDAP

- Ping

Se hace ping a cada uno de los 2 servidores esclavos ldap

10.29.114.237

10.29.114.238

INSTRUCTIVO REPARAR FALLA O ANOMALIA EN DATOS E INTERNET

CODIGO: 121P10I002 VERSION: 2.0 FECHA: 2012/08/24

Página 12 de 12

- Telnet - se verifica que el servidor remoto este corriendo el ldap haciendo un telnet a cada

servidor puerto 389:

Conectividad con los BRAS

- Ping

Se hace ping a los diferentes BRAS

10.29.11.20 sfd

10.29.12.20 ver

10.29.14.20 gua

10.29.15.20 col

10.29.16.20 par

- Peticiones en los log

Verificar que en los log estén llegando peticiones de los diferentes BRAS

tail –f /opt/Lucent/NavisRadius/run/ DB2009****.log

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 1 de 20

1. OBJETIVOS

Monitorear los diferentes equipos que componen la Red Multiservicios (RMS) y el nodo de Internet que están relacionados directamente en los servicios de datos e Internet de EMCALI E.I.C.E.- E.S.P

2. ALCANCE

El procedimiento inicia con la verificación del monitoreo de los equipos del nodo de Internet (tráfico de enlaces en troncales, peticiones de autenticación y control de temperatura de servidores) y los dispositivos que componen la RMS (en las capas de enlace y red).

3. IDENTIFICACION DE LA ACTIVIDAD

PROCESO SUBPROCESO ACTIVIDAD PROCEDIMIENTO

Operar y mantener telecomunicaciones

Ejecutar la Operación y el Mantenimiento de los Sistemas de

Telecomunicaciones

Ejecutar la operación y

mantenimiento del sistema de control

Monitorear Y Gestionar Equipos

De La Red De Datos E Internet

Fuente: Modelo de Operación por Procesos de EMCALI EICE ESP.

4. DEFINICIONES

4.1. MONITOREAR (SERVIDORES DE CONTROL):

Realizar seguimiento visual de una interfaz que representa la operación de un servidor en tiempo real. (Fuente:� Departamento Multiservicios, Área funcional Administración Departamento)

4.2. GESTIONAR (REPORTES DE FALLA)

Tramitar la reparación de los reportes de fallas efectuando las tareas pertinentes para tal fin ya sea mediante enrutamiento o efectuando el cierre de los mismos. (Fuente: Departamento Atención y Soporte al servicio, Área funcional Diagnostico y Pruebas)

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 2 de 20

4.3. TICKET

Es un reporte consolidado que especifica un evento, donde se detalla: número de ticket, descripción y fecha del evento. (Fuente:� Departamento Multiservicios, Área funcional Administración Departamento)

4.4. RMS

Acrónimo de red multiservicios. (Fuente:� Departamento Multiservicios, Área funcional Plataforma de Gestión)

4.5. NODO DE INTERNET

Es un área funcional que se encarga de ejercer el control de acceso a Internet a los usuarios de EMCALI. (Fuente:�Departamento Multiservicios, Área funcional Plataforma de Gestión)

4.6. BITÁCORA

Documento que por lo general se lleva en un procesador de palabras cuyo fin es registrar todas las novedad o información general de un turno. (Fuente:�Departamento Multiservicios, Área funcional Plataforma de Gestión)

5. GENERALIDADES

� Ver generalidades en el anexo

6. DESCRIPCIÓN

6.1. EQUIPO Y HERRAMIENTA UTILIZADOS �

� Acceso a la aplicación Infraestrucxure de APC (UPS, sistema de aire acondicionado) (Dirección IP 10.29.10.84)

� Acceso a la aplicación gestión Cacti con perfil de turno (Dirección IP 10.29.10.71 | Cacti).

� Acceso a la aplicación NETNUMEN perfil de turno. � Acceso Sistema de Gestión ADSL con perfil de turno. � Acceso al aplicativo Ticket con perfil de turno. � Acceso al aplicativo gestión valida. � Acceso al Servicio VNC de monitoreo con perfil de turno (Dirección IP 10.29.10.126:9 |

VLAN Gestión).

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 3 de 20

� Lista de contactos de soporte (Gestión Cacti – Contactos). � Cuenta de correo electrónico asociado al alias de [email protected]. � Lista telefónica del personal de ronda.

6.2 NORMAS DE SEGURIDAD

No aplica

6.3 INSTRUCCION

Ver anexos

7. DOCUMENTOS RELACIONADOS

� Monitorear y Gestionar equipos de datos e Internet 121P10

7.1. DOCUMENTOS INTERNOS

��������

7.2. REGISTROS

��������

7.3. DOCUMENTOS EXTERNOS

��������

8. OBSERVACIONES

En la elaboración del procedimiento participaron:

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 4 de 20

Elaborado por: Erika González

Cargo: Pasante

Fecha: 2012/08/27

Firma:

Revisado por: David Blandón

Cargo: Ingeniero de Conmutación

Fecha: 2012/08/27

Firma

Aprobado por: Jorge Martínez

Cargo: Director de Ingeniería

Fecha: 2012/08/27

Firma

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 5 de 20

9. ANEXOS

Anexo 1: Actividades de Monitoreo de la RMS y Nodo Internet

ACTIVIDADES DE MONITOREO

1. MONITOREO DE RMS.

1.1. Tráfico de utilización de interfaces por ANILLOS.

1.2. Tráfico de utilización de interfaces en BRAS.

1.3. Tráfico de utilización de interfaces ROUTERS DE BORDE(GER).

1.4. Tráfico de utilización de interfaces en CANALES INTERNACIONALES (Culumbos).

1.5. Revisión de Gráfico weathermap del Servidor de Gestión CACTI.

1.6. Gestión de eventos (alert, critical, debug, error, informational, notice, warning) de la RMS vía protocolo “SYSLOG” en Servidor de Gestión CACTI.

1.7. Revisión disponibilidad de equipos, mediante el módulo “Monitor” del Servidor de Gestión CACTI de:

1.7.1 La RMS (switch y router)

1.7.2 Puntos de acceso de WiFi (equipos DSL/AP)

2. MONITOREO NODO INTERNET

2.2.1. Tráfico de utilización de interfaces de Plataforma de Correo.

2.2.2. Tráfico de utilización de interfaces de Servicio STREAMING (Corrillo de MAO).

2.2.3. Tráfico de utilización de interfaces de plataforma de HOSTING (Servicio).

2.2.4. Revisión periódica sistema de aire acondicionado y suministro eléctrico del nodo de Internet mediante el aplicativo ISX-MANAGER de APC.

2.2.5. Revisión de Servidores de Autenticación RADIUS (AAA)( anubis-3a, anubis-4b y osiris-3a.)

2.2.6. Verificar alarmas físicas de servidores.

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 6 de 20

2.2.7. Servidores DNS (operación y verificación de divulgación de dominios por servidor)

3. SOPORTE

3.1. Soporte Técnico a problemas generales con referente a temas de navegación y autenticación a los supervisores de soporte técnico de EMCALI.

3.2. Problemas de Autenticación de IP Fijas e IP Dinámicas

3.3. Soporte de Eventos Temporales

4. REGISTROS

4.1. Bitácora de los Turnos.

5. SEGUIMIENTO Y SOLUCIONES

5.1. Tickets de ADSL – Cola de nodo servicio

5.2. Tickets de Canales Internacionales.

5.3. Tickets de Conmutados.

6. Elementos y suministros

• Acceso a la aplicación InfrastruXure de APC (UPS, sistema de aire acondicionado) (Dirección IP 10.29.10.84)

• Acceso a la aplicación gestión Cacti con perfil de turno (Dirección IP 10.29.10.71 | Cacti) • Acceso a la aplicación NETNUMEN perfil de turno • Acceso Sistema de Gestión ADSL con perfil de turno • Acceso al aplicativo Ticket con perfil de turno • Acceso al aplicativo gestión valida • Acceso al Servicio VNC de monitoreo con perfil de turno (Dirección IP 10.29.10.126:9 | VLAN

Gestión) • Clave de acceso para llamadas a teléfonos celulares y de larga distancia • Lista de contactos de soporte (Gestión Cacti – Contactos) • Cuenta de correo electrónico asociado al alias de “[email protected]

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 7 de 20

• Lista telefónica del personal de ronda

7. DESCRIPCIÓN

7.1 MONITOREO DE SUMINISTRO ELÉCTRICO Y EL SISTEMA DE AIRE ACONDICIONADO DEL NODO INTERNET

Esta actividad tiene por objeto monitorear el suministro eléctrico de los dispositivos y verificar la temperatura del nodo Internet. La herramienta utilizada es el aplicativo APC InfrastruXure Manager, que ofrece funcionalidades básicas para visualizar los estados de los elementos PDU y AAA. El acceso se obtiene de la siguiente manera:

� Verificar conectividad a la VLAN Gestión. � Configurar la tarjeta de red en el rango de direccionamiento (10.29.110.X) � Ejecutar el navegador Web y visitar la URL http://10.29.110.84 � Descargar el software cliente IsxGui � Ingresar el nombre de usuario y la contraseña � En la pantalla inicial verificar que los íconos muestren estado normal (verde)

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 8 de 20

� Para verificar la temperatura hacer doble clic en el ícono de dispositivo refrigeración del aire acondicionado “10.29.110.92”

� Ingresar el nombre de usuario y la contraseña

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 9 de 20

� Para verificar el suministro eléctrico del nodo (UPS o energía externa) hacer doble clic en SAI “10.29.110.90”. en status puede verse de la siguiente forma:

o On line : Suministro de energía externo o On Battery: Suministro de energía por UPS

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 10 de 20

� Para mas detalles ver la opción: Symetra 100K

� Después de generar el registro se pueden observar la descripción y los tipos de evento ocurridos en la fecha seleccionada.

7.2 MONITOREO DE TRAFICO DE CANALES INTERNACIONALES, RED MULTISERVICIO Y GATEWAY DE CORREO

Para esta actividad se debe accesar al aplicativo gestión Cacti y observar las interfases gráficas de monitoreo. Como herramienta de apoyo se puede utilizar servicio VNC de monitoreo para visualizar las interfases más importantes .

Se recomienda establecer una sesión Web con el sistema de gestión Cacti que proporciona las interfases gráficas que muestran los enlaces a monitorear. El acceso se obtiene siguiendo los pasos a continuación:

� Verificar conectividad a la VLAN Gestión. � Configurar la tarjeta de red en el rango de direccionamiento (10.29.10.X) � Ejecutar el navegador Web y visitar la URL: http://10.29.10.71/cacti/� Ingresar el nombre de usuario y la contraseña

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 11 de 20

� Para ejecutar las tareas asociadas a esta actividad verificar de manera repetitiva las siguientes secciones:

o Graphs: � Canales Internacionales : EMCALI � CANAL INTERNET � Anillos de interconexión: EMCALI � ANILLOS RMS � Anillo RMS “N”

(N=1,2,3,4,5,6) � Gateway de correo: EMCALI � Servidores � Correo

o SysLogs o NetMaps:

� Diagrama topológico red Multiservicio o Monitor o Escalamiento

� Niveles de soporte Internexa o Contactos

� Datos de contacto para enrutamiento de anomalías y fallas

Recomendaciones:

• En caso de falla o comportamiento anómalo del tráfico de los canales internacionales se debe contactar a los respectivos Carrier para generar un número de ticket.

• En caso de detectar problemas con los enlaces mostrados en la interfaz gráfica NetMaps se debe contactar inmediatamente al AOM, telefónica de Colón y reportar el evento.

• Para más detalles del servicio VNC de monitoreo consultar el instructivo de operación.

7.3 VERIFICACIÓN DE SERVICIOS DNS

7.3.1 El monitoreo de los servicios DNS se debe hacer por línea de comandos de la siguiente manera:

� Establecer una sesión PPPoE � Ir a Inicio � Ejecutar � teclear “cmd” � Verificar los DNS predeterminados por la sesión con el comando ipconfig -all

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 12 de 20

� Los DNS usuarios predeterminados para los clientes de internet deben ser: o 200.29.96.23 (DNS 4) o 200.29.96.24 (DNS 5) o 200.29.104.24 (DNS 6)

� Los DNS dominios predeterminados para los servidores externos deben ser (No es para usuarios de Internet):

o 200.29.96.22 (DNS 1) o 200.29.96.27 (DNS 2) o 200.29.104.22 (DNS 3)

� Verificar la resolución de nombres de dominio de los portales Web comunes (Google, Yahoo, Hotmail, etc.) con el comando nslookup.

� Para verificar un servicio servicio DNS diferente al predeterminado ejecutar el comando nslookup, server A.B.C.D y el nombre de dominio a resolver.

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 13 de 20

7.3.2 Las siguientes actividades se desarrollan cuando manifiesta que existe problema para entrar a una pagina determinada:

Si reportan un dominio terminado en .com

Entrar a la página www.networksolutions.com

WHOIS Search

Verificar los resultados de

Domain servers in listed order:

A.NS.ULTSEARCH.COM 66.116.109.47

B.NS.ULTSEARCH.COM 66.116.109.48

Record created on: 1997-08-22 00:00:00.0

Database last updated on: 2008-06-13 14:03:54.043

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 14 de 20

Domain Expires on: 2012-08-21 00:00:00.0

Para dominio terminados en .co

Entrar a la página www.nic.co

Luego click en el botón WHOIS

Digitar el nombre del dominio

Verificar los DNS

Servidor Primario: ns1.datapipe.net

Servidor Secundario: ns2.datapipe.net

Fecha de aprobación: 22-JUN-2001

Fecha última modificación:

-------------------------------------------------------

También pueden verificar otros valores como ip y estado resumido en la página http://www.domaintools.com/

-------------------------------------------------------

Si los DNS resuelven el dominio y desean verificar si la página abre desde otro sitio pueden probarlo a través de www.megaproxy.com

--> TRY IT FREE

Digitan la dirección en ADDRESS:

Surf

-----------------------------------------------------

Otra página de herramientas es. www.dnsstuff.com

7.4 MONITOREO DE SERVICIOS RADIUS AAA

El comportamiento de los servicios RADIUS AAA (Authentication, Authorization, Accounting) se puede observar en los monitores del centro de gestión o utilizando el servicio VNC de monitoreo .

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 15 de 20

Los servicios Radius AAA son:

1. Autenticacion Master | 10.29.114.197: Servicio RADIUS AAA para usuarios con IP fija y funciones de accounting (contabilidad) ADSL

2. Autenticacion Slave | 10.29.114.222: Servicio RADIUS AAA primario para usuarios con IP dinámica en los anillos 1,2,3 y secundario en los anillos 4,5,6

3. Autenticacion Slave | 10.29.114.235: Servicio RADIUS AAA primario para usuarios con IP dinámica en los anillos 4,5,6 y secundario en los anillos 1,2,3

La distribución visual en los monitores de gestión es como se muestra a continuación:

7.5 MONITOREO PERMANENTE DE SERVIDORES Y SERVICIOS

Para el monitoreo continuo de los servidores y/o servicios críticos que se encuentren susceptibles a fallas o intermitencias se recomienda utilizar la herramienta que provee funcionalidades para monitorear varios tipos de servidores y los servicios que ejecutan.

���

����� �� ��

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 16 de 20

La aplicación permite automatizar la ejecución de varios tipos de prueba y definir mecanismos de notificación de alarmas (visuales, auditivas, mensajería, etc.) lo que resulta útil para dar cumplimiento de los objetivos de la disponibilidad.

8. SOPORTE TELEFÓNICO A LAS ÁREAS INVOLUCRADAS CON EL SERVICIO DE INTERNET

Para la disponibilidad se cuenta con las líneas 5210023, 5210010, 8998118 para atender todo requerimiento de soporte, gestión de alarmas y enrutamiento de fallas a las siguientes áreas:

� Soporte técnico telefónica de Peñón � Equipo AOM de telefónica Limonar � Soporte técnico de Columbus

Usualmente se tratan los siguientes temas:

� Inconvenientes con usuarios IP fija: Tomar los datos de cliente y la causa del problema y registrarlos en el reporte de novedades del turno

� Problemas de autenticación general: Preguntar cuales son los sectores involucrados, verificar los enlaces de los anillos y el trafico de los BRAS asociados al problema

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 17 de 20

� Problemas de navegación general: Determinar la ubicación en la que se está presentado el inconveniente, y realizar una verificación del tráfico desde su origen hasta el canal internacional

� Problemas de ausencia de acceso a Internet masivos: Verificar el trafico en ambas direcciones desde la ubicación determinada

� Problemas de DNS: Verificar el estado de los servidores DNS en cuanto a procesamiento y funcionamiento

� Consultas de direcciones IP: Determinar direcciones IP fijas para su consulta o verificación.

9. MONITOREO DE HARDWARE, CONECTIVIDAD Y ATENCION DE FALLAS EN SERVIDORES

9.1 MONITOREAR CONECTIVIDAD:

Para monitorear el estado actual de las interfaces de red que están activas en el servidor

Se ejecuta el comando:

# ifconfig muestra el estado de todas las interfaces # ifconfig + (nombre de la interface) Ejemplo: ifconfig eri

eri0: flags=863<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 1

inet 10.0.0.112 netmask ffffff80 broadcast 10.8.48.127

ether 8:0:20:b9:4c:54

Muestra solo el estado de solo una interface

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 18 de 20

Variable Screen Output Descripción

Nombre de la interface de red

eri0 Indica el nombre de la interface tal cual como esta configurada en el servidor.

Interface status

flags=863<UP Muestra el estado de la interface, incluye banderas y su respectivo código la cual se debe consultar el sitio web del fabricante sun.com. Adicional también informa si la tarjeta de red esta Arriba (UP) o no inicializada (DOWN).

Broadcast status

BROADCAST Indica que la interface soporta IPv4 broadcasts.

Multicast MULTICAST, IPv4

Muestra que la interface soporte transmisiones tipo multicast.

Maximum transmission unit

mtu 1500 Muestra el tamaño máximo de transferencia de 1500 octets.

IP address inet 10.0.0.112 Muestra la dirección IPv4 o IPv6 asignada en la interface. Ejemplo la interface eri0 tiene la ip IPv4 address 10.0.0.112.

Netmask netmask ffffff80 Muestra la IPv4 netmask de esta interface de red.

MAC address ether 8:0:20:b9:4c:54

Muestra la interface's Ethernet layer address.

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 19 de 20

9.2 Monitorear Hardware:

Para ver los parámetros de configuración del sistema y el estado del hardware, se utiliza los siguientes comandos.

• Comando prtconf

• Comando prtdiag

• Comando sysdef

• Comando format

Comando prtconf:

El comando prtconf de Solaris muestra la configuración del sistema. Su resultado incluye:

• La cantidad total de memoria.

• La configuración de los periféricos del sistema presentada en forma de árbol de dispositivos.

• Este comando tiene muchas opciones. Consulte la página del comando man de prtconf para ver su sintaxis, las opciones y ejemplos.

Comando prtdiag

El comando prtdiag de Solaris muestra la siguiente información al dominio del sistema:

• Configuración

• Diagnóstico

• Temperatura

• Sensor

• Para conocer la sintaxis, opciones y ejemplos del comando, consulte la página del comando man de prtdiag.

Comando sysdef

La utilidad sysdef de Solaris muestra la definición actual del sistema en formato de tabla. Presenta:

• Todos los dispositivos de hardware

• Seudodispositivos

• Dispositivos del sistema

INSTRUCTIVO MONITOREAR RMS Y NODO DEINTERNET�

CODIGO: 121P10I001 VERSION: FECHA: 2012/08/27

Página 20 de 20

• Módulos cargables

• Valores de determinados parámetros ajustables del núcleo

Este comando genera su salida analizando el archivo de nombres (listanombres) del sistema operativo de arranque y extrayendo de él la información de configuración. La listanombres predeterminada del sistema es /dev/kmem.

Para conocer la sintaxis, opciones y ejemplos de sysdef, consulte la página del comando man correspondiente.

Comando format

La utilidad format de Solaris, que se emplea para formatear unidades, aunque también se puede usar para ver los nombres de dispositivos lógicos y físicos. Para conocer la sintaxis, opciones y ejemplos de este comando, consulte la página del comando man de format.

Para consultar más opciones sobre los comandos antes nombrados dentro del sistema operativo del servidor tiene la opción de correr el comando man mas el nombre del comando para verificar el sistema: Ejemplo:

• man prtconf

• man prtdiag

• man sysdef

• man format

Atención de Fallas:

Si al ejecutar los comandos anteriores se observa que hay fallas en el hardware del servidor, se debe llamar a soporte de oracle y abrir un caso para que ellos envíen un ingeniero a que revisen el servidor y el hardware que este presentando la falla, hay que tener a la mano el serial del servidor, adicional nosotros debemos solicitar a oracle un código del ticket y enviar un mail informando de este caso a [email protected].

INSTRUCTIVO IMPLEMENTACION DE UN SERVICIO EN UN SERVIDOR�

CODIGO: 121P13|002 VERSION: 2.0 FECHA: 2012/09/03

Página 1 de 10

1. OBJETIVO

Definir los parámetros básicos de implementar un servicio en un servidor como modelo base a aplicar en el Nodo de Internet de la Central Telefónica de San Fernando de Emcali E.I.C.E. E.S.P.

2. ALCANCE

El procedimiento inicia cuando se desea instalar un servicio en un servidor y termina con el servicio funcionando.

3. IDENTIFICACION DE LA ACTIVIDAD

PROCESO SUBPROCESO ACTIVIDAD PROCEDIMIENTO

Operar Y Mantener Telecomunicaciones

Ejecutar la Operación y el Mantenimiento de

los Sistemas de Telecomunicaciones.

Ejecutar la Operación y el Mantenimiento de

los Sistemas de Telecomunicaciones.

Administrar servidores del

sistema de Telecomunicaciones.

Fuente: Modelo de Operación por Procesos de EMCALI EICE ESP.

4. DEFINICIONES

SERVIDORES: Termino utilizado que identifica un recurso de hardware para una o mas aplicaciones en especifico. (Fuente: Departamento Multiservicios��

ISP: Acrónimo de Proveedor de Servicios de Internet. (Fuente: Departamento Multiservicios).

SERVICIO: Nombre empleado para signar una función que provee una utilidad determinada. (Fuente: Departamento Multiservicios).

DIRECCIONAMIENTO IP: Termino que designa la ubicación lógica de un dispositivo y se basa en una notación decimal de 4 octetos que identifica los recurso de direccionamiento de un sistema. (Fuente: Departamento Multiservicios, Área Funcional Administración Departamento).

INSTRUCTIVO IMPLEMENTACION DE UN SERVICIO EN UN SERVIDOR�

CODIGO: 121P13|002 VERSION: 2.0 FECHA: 2012/09/03

Página 2 de 10

POLITICA: Nombre asignado al conjunto de instrucciones que permiten o niegan la disponibilidad de un servicio. (Fuente: Departamento Multiservicios, Área Funcional Administración Departamento).

MONITOREAR (SERVIDORES DE CONTROL): Realizar seguimiento visual de una interfaz que representa la operación de un servidor en tiempo real. (Fuente: Departamento Multiservicios, Área Funcional Administración Departamento).

GESTIONAR (REPORTES DE FALLAS): Realizar diligencias conducentes al logro de un negocio. Tramitar la reparación de los reportes de fallas efectuando las tareas pertinentes mediante el enrutamiento o el cierre de los mismos. (Fuente: Departamento Atención y Soporte al Servicio, Área Funcional Diagnostico y Pruebas).

RMS: Acrónimo de Red Multiservicios. (Fuente: Departamento Multiservicios, Área Funcional Plataforma de Gestión).

NODO DE INTERNET: Es un área funcional que se encarga de ejercer el control de acceso a Internet a los usuarios de EMCALI. (Fuente: Departamento Multiservicios, Área Funcional Plataforma de Gestión).

5. GENERALIDADES

Pasos a seguir para instalar un servicio en un servidor:

1. Definir la maquina virtual.

2. Verificar en el documento Asignación de Recursos Emcali.

3. Definir direcciones de IP para la instalación.

4. Definir el Blade donde se instalara el servicio.

5. Definir el LDOM (Ver Anexo crear Ldom).

6. Definir el tamaño de los discos en el documento de Asignación de Recursos.

7. Creación de discos en el Storage.

8. Actualizar el numero de LUN’s en el documento de Asignación de Recursos.

9. Crear las Zonas (Ver Anexo de Creación de Zonas).

INSTRUCTIVO IMPLEMENTACION DE UN SERVICIO EN UN SERVIDOR�

CODIGO: 121P13|002 VERSION: 2.0 FECHA: 2012/09/03

Página 3 de 10

6. DESCRIPCION

6.1. EQUIPO Y HERRAMIENTA UTILIZADOS.

• Tabla de Asignación de Recursos.

• Tabla de direccionamiento de servidores.

• Pagina Web.

6.2. NORMAS DE SEGUIRIDAD.

• No aplica.

6.3. INSTRUCCION

ID TAREA DESCRIPCION

1 Instalar zona de ambiente de pruebas

Ver Anexo 1. Referente al ambiente de pruebas

2

Definir e instalar Software de Servicios a implementar en el Servicios

Identificar el software de servicio que se instalará en el recurso. Ejemplo: Servicios IP, DHCP, etc.

3 Configurar Servicio en el Servidor

Hace referencia al conjunto de IP que serán usadas para identificar el servidor y poder usar el servicio.

4 Verificar funcionamiento del Servicio

Permite verificar si el servicio es funcional para la cual se instaló

5 Crear hoja de vida del Servidor y registrar la aplicación

Se adiciona registros en formato Hoja de Vida de Servidores.

7. DOCUMENTOS RELACIONADOS

• Administrar servidores de telecomunicaciones 121P13

INSTRUCTIVO IMPLEMENTACION DE UN SERVICIO EN UN SERVIDOR�

CODIGO: 121P13|002 VERSION: 2.0 FECHA: 2012/09/03

Página 4 de 10

7.1. DOCUMENTOS INTERNOS

• Ninguno

7.2. REGISTROS

• Hoja de vida Software 116P02F003.

7.3. DOCUMENTOS EXTERNOS

Manuales implementación Servicios IP.

8. ANEXOS

Anexo 1.

Planear e Implementar Ambiente de Pruebas.

Disponibilidad de Recursos:

Para realizar esta labor se verifica en la tabla de recursos, las maquinas disponibles según el espacio, procesamiento y memoria, de acuerdo a la función requerida.

Tener un ambiente de pruebas que permita realizar los test de verificación necesario antes de salir a producción.

Implementar Sistema:

Se escogió la modalidad de contenedores para realizar esta labor, en el servidor SAFE_011, que cuenta con 8 gigas de memoria, 16 procesadores virtuales y 20 gigas de espacio asignadas para la maquina de pruebas.

• Se realizó el montaje del sistema operativo Solaris 10

• Se parcho la maquina

• Se implementaron los paquetes bases de la distribución de Solaris.

INSTRUCTIVO IMPLEMENTACION DE UN SERVICIO EN UN SERVIDOR�

CODIGO: 121P13|002 VERSION: 2.0 FECHA: 2012/09/03

Página 5 de 10

• Se instalaron los paquetes de LDAP, RADIUS, DHCP y demás que se solicitaron para cumplir con las pruebas.

Este sistema se haya actualmente con la IP 10.28.95.37 y tiene un contenedor con el nombre de test.

Acceso:

El acceso a este sistema lo tiene el personal de Web máster y el Administrador de Red

9.

9.

9.

9.

9.

9.

9.

9.

9.

9.

9.

9.

9. OBSERVACIONES

��

��

��

��

��

Elaborado por: Erika González

Cargo: Pasante

Fecha: 2012/09/03

Firma

Revisado por: David Blandón

Cargo: Ingeniero de Conmutación

Fecha: 2012/09/03

Firma

Aprobado por: Jorge Martínez

Cargo: Director de Ingeniería

Fecha: 2012/09/03

Firma

INSTRUCTIVO IMPLEMENTACION DE UN SERVICIO EN UN SERVIDOR�

CODIGO: 121P13|002 VERSION: 2.0 FECHA: 2012/09/03

Página 6 de 10

���������

��

��

INSTRUCTIVO IMPLEMENTACION DE UN SERVICIO EN UN SERVIDOR�

CODIGO: 121P13|002 VERSION: 2.0 FECHA: 2012/09/03

Página 1 de 10

��

INSTRUCTIVO IMPLEMENTACION DE UN SERVICIO EN UN SERVIDOR�

CODIGO: 121P13|002 VERSION: 2.0 FECHA: 2012/09/03

Página 2 de 10

���

INSTRUCTIVO IMPLEMENTACION DE UN SERVICIO EN UN SERVIDOR�

CODIGO: 121P13|002 VERSION: 2.0 FECHA: 2012/09/03

Página 3 de 10

INSTRUCTIVO IMPLEMENTACION DE UN SERVICIO EN UN SERVIDOR�

CODIGO: 121P13|002 VERSION: 2.0 FECHA: 2012/09/03

Página 4 de 10

VERIFICAR OPERACIÓN AAA�

CÓDIGO: 121P08 VERSIÓN: 2.0 FECHA: 2012/08/28

Página 1 de �

1. OBJETIVOS

Establecer los pasos que se debe ejecutar para realizar la validación de la operación del sistema de control del AAA del ISP en la central telefónica EMCALI para el correcto funcionamiento del servicio de internet.

2. ALCANCE

Inicia cuando se detecta alguna novedad (evento) en el servicio ó una verificación de operación AAA, y finaliza cuando se hace el reporte de la revisión o solución. Involucra la Unidad Estratégica de Negocio de Telecomunicaciones, específicamente el Departamento de Multiservicios.

3. IDENTIFICACION DE LA ACTIVIDAD PROCESO SUBPROCESO ACTIVIDAD

Operar y mantener telecomunicaciones

Operar y Mantener el Sistema de Control

Ejecutar la operación y mantenimiento del sistema

de control

Fuente: Modelo de Operación por Procesos EMCALI EICE ESP.

4. DEFINICIONES �

AAA: Servicio de control de usuarios cuya función es autenticar, autorizar y acreditar cada petición. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

AUTENTICACIÓN: Proceso por el cual se comprueba identidad de usuario, la cual se consigue mediante la presentación de una propuesta de identidad (nombre usuario) y la demostración de estar en posesión de las credenciales que permiten comprobar contraseña. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

AUTORIZACIÓN: Consecución de privilegios específicos (incluido ninguno) a un usuario basándose en su identificación (autenticado), en los privilegios solicitados y en el estado actual del sistema. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

B-RAS: Equipo de control de usuarios y agregador se sesiones (terminar sesión PPPoE). (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

VERIFICAR OPERACIÓN AAA�

CÓDIGO: 121P08 VERSIÓN: 2.0 FECHA: 2012/08/28

Página 2 de �

CANAL INTERNACIONAL: Proveedor o carrier externo que se intercomunica con el núcleo de Internet. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

CONFIGURACIÓN: Secuencia establecida de comandos para realizar algún tipo de actividad. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

CORRECTIVO: Realizar cambio con el fin de alinear el funcionamiento, al objetivo de desempeño. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

CUANTIFICACIÓN: Del ingles Accounting; se refiere al seguimiento del consumo de los recursos de red por los usuarios. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

EVENTO: Es un suceso que afecta la operación de un servicio o un área con efectos de la no prestación de una actividad. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

FALLA EN LA RED: Anomalía dentro de las interconexiones, servicios, equipos o servidores de la empresa. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

GESTIONAR: Dirigir y controlar el funcionamiento de un sistema. (Fuentes: NTC ISO 9000:2000).

INTERCONEXIÓN: Es la vinculación de recursos físicos y soportes lógicos, incluidas las instalaciones esenciales necesarias, para permitir el interfuncionamiento de las redes y la interoperabilidad de servicios de telecomunicaciones. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

INTERFUNCIONAMIENTO DE LAS REDES: Es el correcto funcionamiento de dos redes interconectadas. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

INTEROPERABILIDAD DE LOS SERVICIOS: Es el correcto funcionamiento de los servicios que se prestan sobre dos redes interconectadas. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

VERIFICAR OPERACIÓN AAA�

CÓDIGO: 121P08 VERSIÓN: 2.0 FECHA: 2012/08/28

Página 3 de �

ISP (INTERNET SERVICE PROVIDER) O NODO DE INTERNET:Es un área funcional que se encarga de ejercer el control de acceso a internet a los usuarios de EMCALI. (El concepto en EMCALI es diferente al exterior). (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

MASIVO: Falla parcial o total de un grupo de usuarios. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

MONITOREAR (SERVIDORES DE CONTROL): Realizar seguimiento visual de una interfaz que representa la operación de un servidor en tiempo real. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

MONITOREO (SERVIDORES DE CONTROL): Verificación de una serie de variables críticas que corren en un sistema operativo, para ejercer un control sobre el servidor. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

NIVEL DE TRÁFICO: Volumen de ocupación de un canal. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

PROVEEDOR: Entidad que suministra productos y/o servicios a una organización. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

RED: Elementos de interconexión que permiten prestar servicios a un conjunto de usuarios. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

REGISTRO: Documento que presenta resultados obtenidos o proporciona evidencia de actividades desempeñadas. (Fuentes: NTC ISO 9000:2000).

SERVIDOR: Es un tipo de Hardware, el cual permite compartir recursos físicos y lógicos en una red de área local. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

SISTEMA OPERATIVO: Es una secuencia de código que genera un programa de operación en el cual maneja un interfaz humano-máquina para una actividad o fin determinado. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

TICKET: Es un reporte consolidado que especifica un evento, donde detalla: número de ticket, descripción y fecha del evento. (Fuente: Departamento Multiservicios, Área funcional Administración Departamento).

VERIFICAR OPERACIÓN AAA�

CÓDIGO: 121P08 VERSIÓN: 2.0 FECHA: 2012/08/28

Página 4 de �

5. GENERALIDADES

• Herramientas de Monitoreo • La bitácora de turno es un registro que se crea de manera virtual y su medio de

transmisión es el correo electrónico. • El ticket Interno y con el proveedor no tienen forma física, se generan de forma virtual

para generar el registro.

6. RESPONSABILIDAD Y AUTORIDAD �

La responsabilidad y autoridad de este procedimiento reside en el Jefe de Departamento Multiservicios.

7. DOCUMENTOS RELACIONADOS

7.1 DOCUMENTOS INTERNOS

• Procedimento “Verificar Operación BRAS” • Procedimento “Monitorear servidores ISP” • Procedimento “Gestionar servidores ISP” • Instructivo “Verificar peticiones AAA”

7.2 REGISTROS

• Se realizan de manera virtual • Bitacora de Turno

7.3 DOCUMENTOS EXTERNOS

• Request For Comments (RFC)

8. FLUJOGRAMA DEL PROCEDIMIENTO

Ver Flujograma del procedimiento (Verificar Operación AAA)

VERIFICAR OPERACIÓN AAA�

CÓDIGO: 121P08 VERSIÓN: 2.0 FECHA: 2012/08/28

Página 5 de �

9. IDENTIFICACION DE CONTROLES

Ver Anexo 2. Identificación de Controles.

10. ANEXOS

Anexo 1. Flujograma del procedimiento Verificar Operación AAA Anexo 2. Identificación de Controles

11. Observaciones

Participaron en la realización del procedimiento:

Elaborado por:

Erika González

Cargo:

Pasante

Fecha:

2012/08/28

Firma

Revisado por:

David Blandón

Cargo:

Ingeniero de Conmutación

Fecha:

2012/08/28

Firma

Aprobado por:

Jorge Martínez

Cargo:

Director de Ingeniería

Fecha:

2012/08/28

Firma

VERIFICAR OPERACIÓN AAA�

CÓDIGO: 121P08 VERSIÓN: 2.0 FECHA: 2012/08/28

Página 6 de �

ANEXO.