migración y actualización del servicio aaa y aplicativos
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.
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