Retomando la idea de Steve Jobs de la intersección entre tecnología y las artes liberales al momento de adoptar nuevas tecnologías

Como tecnólogos, muchas veces nos enfocamos en querer posicionar y convencer a nuestros usuarios de un servicio de TI que pensamos es de gran valor para ellos (por supuesto desde nuestro punto de vista). Sin embargo, insistimos en la difusión y adopción de nuestros servicios desde una perspectiva de tecnólogos y para tecnólogos (geeks), ¿a que me refiero?, a querer que nuestros usuarios adopten nuevos servicios basados en nuevas tecnologías por las monerías muy especificas que hacen (features o facilidades). ¿Que sucedería si en vez de ello, retomamos la idea de Steve Jobs de intentar lograr un balance entre tecnología y lo que denominaba las artes humanistas?, es decir, hacer que los usuarios adopten las nuevas tecnologías ayudándolos a crear un sentido de identidad con ellas.

¿Como contribuir a ese cambio desde nuestra posición como los responsables de la elección de nuevas tecnologías en nuestra empresa?, les compartiré una idea que es solo eso... una de muchas formas distintas de realizar esta contribución.

Hoy día, esencialmente, buscamos a los diferentes proveedores de tecnología (fabricantes y canales de venta) para que nos "asesoren" con respecto a las nuevas tecnologías o las nuevas versiones de ellas, con la intención de identificar nuevos features o facilidades que pudieran interesarnos como tecnólogos y como consecuencia a nuestros usuarios de las distintas áreas de negocio. Basado en ello, llevamos a cabo las justificaciones internas necesarias para actualizar o migrar los diferentes componentes tecnológicos para adoptar lo último en tecnología. ¿El resultado más frecuente?, millones de dólares invertidos en tecnología en donde los usuarios del negocio son pocas veces beneficiados al no entregarles mas servicios o de mayor relevancia a los que ya venían utilizando con la "vieja tecnología".

Algunos datos interesantes de empresas en México, elaborado por una importante empresa de telecomunicaciones, encontró los siguientes hallazgos:

• El 50% de empresas que dieron el paso a comunicaciones unificadas en la década pasada con la intención de ofrecerles servicios de nueva generación adicional al tradicional "tono de llamada" a sus usuarios, solo se quedaron con el servicio de voz sin desplegar ningún otro servicio, al dejar para fases posteriores que nunca llegaron, la implementación de esas funciones de valor.
• Un 25% adicional de empresas, agregaron buzón de voz al servicio de voz básico ya que por ser competencia del área de sistemas el correo electrónico y al no poder gestionar la integración entre estos 2 componentes por parte del área de telefonía, no pudieron habilitar el servicio de mensajería unificada (correos de voz enviados al buzón de correo electrónico del usuario para escucharlos desde ahí con un software de reproducción de sonido).
• Solo el 15% de servicios avanzados de comunicaciones unificadas (como buzón de voz en smartphones, chat con servicios de presencia, voz y video; etc.) fueron comprados por empresas, el resto fueron servicios básicos, buzón de voz y softphones. Sin embargo, solo un número reducido de empresas lograron desplegar estos servicios avanzados y entregarlo a los usuarios de negocio por la dependencia del directorio activo y componentes a colocar en la DMZ del acceso a Internet, ambas cosas competencia de otras áreas ajenas al área de telefonía.
• De la totalidad de empresas que compraron la primera generación de soluciones de control de acceso a la red (NAC, Netwok Access Control), solo el 30% consiguió con éxito implementarlas como fueron conceptualizadas.

Aunque hay más hallazgos, con estos ejemplos son suficientes para dar un panorama general de la realidad detrás de las compras millonarias en algunos casos de nuevas tecnologías.

¿Qué pasaría si después de evaluar las nuevas tecnologías, nos tomáramos un tiempo razonable para definir la utilidad de estas tecnologías a las necesidades del negocio y los usuarios como lo sugiere ITIL en sus fases de service strategy y service design?, este es el fundamento de la idea descrita en este artículo, agregar esta fase al proceso de selección y adopción de nuevas tecnologías.

El objetivo principal de esta fase de definición sería, redefinir el catálogo de servicios o aplicaciones a otorgar a los usuarios del negocio independientemente de su función en la organización. Este catálogo, debe contener nombres que deben ser asociados a la necesidad de negocio a apoyar (y que idealmente debe estar nombrada en el plan estratégico de tecnología denominado PET o PETIC), más que a una asociación con la tecnología que principalmente las convertirá en realidad. Para aclarar este primer aspecto, pongamos un ejemplo sencillo.

Uno de los servicios más comunes en toda empresa es el que denominan "servicio telefónico", ahora bien, ¿cual es en realidad el servicio que se habilita al usuario interno?, son llamadas telefónicas, comunicación de audio, audiocomunicación o algo similar; sin embargo, las áreas de telefonía lo denominan pensando en la tecnología asociada y no en el servicio que se le habilitará al usuario. Si ahora, nos concentramos en definir este mismo servicio en función de las necesidades de negocio a apoyar, podríamos definir en realidad varios servicios al usuario a partir de la tecnología de telefonía, tales como:

• Servicio de audiocomunicación (llamadas telefónicas y conferencias de audio con todas las facilidades telefónicas inherentes a esta tecnología como transferencia, esquemas jefe-secretaría, hold, call park, pickup, etc).
• Servicio de experto virtual (marcación a un grupo definido de personas con habilidades en ciertos procesos o áreas de conocimiento, en donde se establecen reglas de tratamiento de las llamadas y encolamiento en caso de encontrarse todos los expertos en llamadas, con fines de asesoramiento a los usuarios internos de la organización). Este servicio puede ser solo audio o audio y video (sesión de videotelefonía).
• Servicio de consulta de información (mediante el cual teléfonos colocados en zonas o kioscos públicos sirven para generar una llamada a una mesa de expertos virtuales, con la intención de ofrecer o aclarar dudas a personas o usuarios externos a la organización). Este servicio al ver que el anterior, puede ser solo audio o audio y video (sesión de videotelefonía).
• Servicio de audioconferencias no programadas (mediante el cual, se marca a una extensión definida y todos los usuarios se enlazarán a una conferencia telefónica en vez de que alguien este enlazando a todos los participantes).
• Servicio de localización de usuario (a través del cual al marcar a la extensión de escritorio, timbrarán simultáneamente, el teléfono fijo y softphones asociados al usuario, así como el celular o cualquier otro numero programado, con la intención de localizar al usuario independientemente de donde se ubique físicamente, con solo conocer su número de extensión).

Todos los servicios anteriores, están basados en la tecnología de telefonía o comunicaciones unificadas como la llaman los principales fabricantes. ¿Notan la diferencia en el cambio de perspectiva entre definir y nombrar servicios basados en la tecnología asociada vs definir los servicios basados en la necesidad de negocio a atender?.

La primera recomendación es entonces, definir los servicios considerando en todo momento, la necesidad de negocio a apoyar o la que contribuirá el servicio definido. O dicho de otra forma, empezar con el fin en la mente (que es tener claro el cómo ayudarán estos servicios al negocio) que es uno de los principios de la gente altamente efectiva, señalados por Stephen Covey).

La segunda recomendación es, definir el catálogo de servicios basado en el nombre o denominación asociada a la función a llevar a cabo por cada servicio y no en la tecnología asociada a hacerlo realidad.

Una vez definido el catálogo de servicios al usuario de acuerdo al cambio de perspectiva explicado, se tienen que definir los dispositivos a través de los cuales se accederán a dichos servicios por parte de los usuarios, alineando este aspecto la tendencia de BYOD (Bring Your Own Device). Hoy día, es sencillamente absurdo limitar el uso de los servicios definidos por la TI a ciertos dispositivos. El caso mas claro, el correo electrónico  no tiene sentido solo dar acceso a este servicio a través de la PC o laptop asignada al usuario en vez de hacerlo mediante las tablets y smartphones de cada usuario.

La tercera recomendación tiene que ver entonces, con ampliar el acceso a los servicios definidos al usuario tanto en el equipo de escritorio asignado (teléfono o videoteléfono), como en la computadora (PC o laptop), tablet y smartphone.

Para dejar aún más claros los resultados de este sencillo cambio de paradigma en la definición y asignación de servicios a los usuarios, así como su contribución al negocio o la estrategia de negocio, les contaré el caso real de una compra de tecnología hecha con el enfoque tradicional de una empresa mexicana y la diferencia que pudo haber obtenido con el enfoque descrito en este articulo.

Mediante el enfoque tradicional

El cliente, realizó la compra de su red de comunicaciones unificadas, bajo la petición siguiente:

• Concurso un catálogo de conceptos que no era más que un listado en excel con los modelos de equipos, marca y cantidad que requería.
• El catálogo de conceptos, venía acompañado de una descripción de características técnicas que debían cumplir los equipos descritos en dicho catálogo (en un documento en word).
• Los equipos y licenciamiento que solicitaba, eran para funciones de un PBX IP, correo de voz, colaboración Web (compartición de la pantalla de un usuario a múltiples asistentes a una reunión remota), chat para usuarios, firewall con funciones de VPNs y demás elementos de comunicaciones (switches, ruteadores, etc).

¿Qué acabó instalando el proveedor ganador con los alcances definidos en el catálogo de conceptos y el documento de especificaciones técnicas?, lo siguiente:

• Telefonía para la cantidad de extensiones ofertadas con algunas facilidades básicas.
• Correo de voz a los usuarios definidos de telefonía.
• El Chat con voz para la cantidad de usuarios adquiridos.
• Acceso vía VPNs a los usuarios que se enteraron de este nuevo proyecto y solicitaron la activación de esta función en sus laptops.
• Servicio de colaboración web para uso interno únicamente, en PCs.

Mediante el enfoque basado en servicios a habilitar en el usuario de negocio

Al quedar terminada la fase de implementación, el cliente contento con la nueva tecnología adquirida, preguntó al proveedor, ¿qué más servicios puedo implementar en mi red con lo que compré?, para poder contestar este cuestionamiento hecho al ejecutivo de cuenta, se solicitó a un consultor interno de la misma empresa que vendió la solución, realizar un análisis de los equipos, software y licencias vendidas. El consultor una vez realizado el análisis, entregó el siguiente catálogo de servicios al usuario, como factibles de implementar sin costo y de manera inmediata ya que solo requería configuración de los equipos adquiridos:

• Servicio de comunicación audio visual
• Comunicación por voz (llamadas) y videollamadas (voz y video en los casos de clientes con software de PC).
• Servicio de oficina móvil
• Conectividad vía VPN a la empresa para accesar a todas las aplicaciones de negocio vía conexión remota (correo electrónico, aplicaciones de CRM, ERP, etc; intranet y demás).
• Servicio de comunicación mediante mensajería instantánea
• Chat para la totalidad de usuarios de la red no solo para la cantidad de usuarios licenciados por la solución de comunicaciones unificadas ya que este servicio no tiene costo para el fabricante (es gratis).
• Servicio de localización de usuario
• Facilidad para el timbrado simultáneo de una llamada entre diversos dispositivos definidos por el usuario (es solo un feature que requiere configuración).
• Servicio de buzón de mensajes
• Correo de voz integrado al servidor de correo electrónico del cliente que es solo configuración sin costo de licencias o hardware.
• Servicio de experto virtual (audio o video)
• Configuración de una facilidad gratuita en el PBX IP para proporcionar una mesa de expertos para fines de dudas en cierto proceso interno o externo a la organización, mediante una sesión de audio o videollamada si se marca desde los softphone con capacidad de video.
• Servicio de comunicación móvil
• Llevar el acceso a los servicios de comunicaciones unificadas (voz, chat, video, acceso a correo de voz, etc. estando conectado remotamente mediante oficina móvil).
• Servicio de reuniones virtuales
• Servicio adicional al servicio de colaboración Web comprado, incluido por 1 año gratis a 50 usuarios para contar con reuniones tanto para participantes internos como externos, en cualquier dispositivo (tablet, smartphone o PC) con grabación de las reuniones llevadas a cabo.  Servicio completamente del tipo Cloud en donde únicamente se requiere asignar el servicio a lo usuarios hablando al centro de atención a clientes (no requiere ninguna infraestructura del cliente).
• Servicio de colaboración social
• Servicio gratis por 1 año para utilizar una herramienta social tipo facebook para colaboración en proyectos internos. Servicio completamente del tipo Cloud en donde únicamente se requiere asignar el servicio a lo usuarios hablando al centro de atención a clientes (no requiere ninguna infraestructura del cliente).
• Servicio de reservación de citas
• Servicio idéntico al experto virtual pero con fines de atención a usuarios externos en trámites a llevar a cabo en la organización y comunicando las citas a las áreas que recibirán a los usuarios externos vía correo electrónico.
• Servicio de kioscos de información
• Extensiones telefónicas configuradas para realizar una marcación automática al descolgarse a un grupo de personas de la organización que provean información de diferente índole con la aplicación del servicio de experto virtual.

¿Qué reacción creen que tuvo el cliente al enterarse que estaba subutilizada la inversión en esta nueva tecnología?...

Mismos equipos en ambos casos..

Misma tecnología en ambos casos...

Mismo costo en ambos casos...

Pero diferente concepción del éxito en la adopción de nuevas tecnologías y su contribución y aplicación al negocio...

Como fin último, debemos llevar el éxito del proyecto a la habilitación y adopción de las nuevas tecnologías por parte de los usuarios del negocio al identificar esa parte humanista que los ayudara en su día a día y a mejorar la forma en como hacen las cosas, con mayor sencillez, para con ello, generar una enorme dependencia de estos servicios de valor que con el tiempo, se convertirán en servicios estratégicos, y no dejar el éxito de todo proyecto de implementación de nuevas tecnologías en lo que comúnmente es denominado por los tecnólogos como la instalación, configuración y puesta en operación de los equipos comprados, no importando si el usuario recibió o no nuevos servicios.

El dilema de eso que significa contar con "alta disponibilidad" ennuestras arquitecturas de tecnología (parte 2 de 3)

Una vez que ya sabemos como realizar el cálculo de disponibilidad de cada equipo individual, tenemos que contestar a la pregunta siguiente: ¿Cuál entonces será el SLA que tiene la red en su conjunto?. Para ello, nos ayudaremos de la figura siguiente.

Para realizar el cálculo de SLAs de la red, se deben definir diferentes escenarios de los cuales se requiere conocer el SLA probable, no es posible simplemente calcular un SLA para toda la red. Los escenarios mostrados en la figura anterior, son los que utilizaremos para el cálculo de SLAs.

Ejemplo 4: Empezaremos con el cálculo del SLA para el escenario de comunicación entre un par de sitios de la red WAN. Para calcular la disponibilidad de la comunicación entre la PC A y el servidor B, requerimos en primer lugar, calcular la disponibilidad de cada elemento que se encuentre en la trayectoria de esta comunicación (switch, ruteador del sitio remoto, ruteador del sitio central, switch de core del sitio central, switch de server farm) como se explicó en la primera parte de este artículo. Es común, no poner atención a que hay un elemento muy importante en este escenario, el SLA del enlace WAN pactado con el carrier. Una vez que tenemos todos los elementos que forman parte de este escenario, para calcular el SLA, la trayectoria de comunicación debe ser tratada como elementos en serie, y utilizar el cálculo descrito en la primera parte de este artículo como sigue.

Disponibilidad del escenario (%) = disponibilidad switch * disponibilidad ruteador remoto * disponibilidad enlace WAN * disponibilidad ruteador central * disponibilidad switch core * disponibilidad switch server farm

Nota.- Nótese que para este ejemplo no contemplamos la disponibilidad propia de los elementos terminales (PC y servidor), en caso que el lector lo considere, deber adicionarlos dentro de cálculo respectivo.

Ejemplo 5: Para el escenario siguiente, tratará de la disponibilidad o SLA en la comunicación de una extensión telefónica (teléfono IP) a la red pública (PSTN), el cálculo de disponibilidad deberá realizarse como sigue:

Disponibilidad del escenario (%) = disponibilidad del teléfono IP * disponibilidad del switch de acceso * disponibilidad del switch de core * disponibilidad del gateway de voz * disponibilidad del enlace de telefonía (troncal analógica o digital)

Vamos ahora a llevar a cabo el cálculo de disponibilidad de un escenario de un servicio de Cloud Computing que tengamos contratado, para fines de este ejemplo, se tratará de un servicio de comunicaciones unificadas (servicio de voz y aplicaciones), mostrado en la siguiente figura.

Ejemplo 6: Si el proveedor de servicios (service provider) de comunicaciones unificadas (UCaaS, Unified Communications as a Service) que tenemos contratado, nos ofreciera un SLA de su nube hasta el equipo de demarcación que éste colocará en el sitio al que se conecta de nuestra red, mediante un ruteador (equipo CPE) propiedad de él, de 99.998%; y nosotros como responsables de la TI interna realizáramos las adecuaciones necesarias en la red LAN que es nuestra responsabilidad, para contar con SLA en ella de 99.99%, ¿cuál sería el SLA del servicio a comprometer con el usuario del videoteléfono ejemplificado en el diagrama?. El cálculo de este escenario, contempla calcular la disponibilidad o SLA de cada elemento individual (switch de acceso al que esta conectado el videoteléfono, el switch de core y el videoteléfono mismo cuya disponibilidad pensemos que sea 99.97%) y posteriormente, realizar el cálculo como elementos en serie en toda la trayectoria previa al ruteador del proveedor, para finalmente considerar el SLA del proveedor de servicios de comunicaciones unificadas en la nube como un solo elemento en serie como sigue:

Disponibilidad de la red LAN (%) = disponibilidad del switch de acceso * disponibilidad switch core

Disponibilidad del servicio de comunicaciones unificadas (%) = disponibilidad de la red LAN * disponibilidad del videoteléfono * disponibilidad proveedor de UCaaS

Disponibilidad del servicio de comunicaciones unificadas (%) = 0.9999 * 0.9997 * 0.99998 = 99.95%

Tercera Conclusión: "Al ser elementos en serie, la disponibilidad del servicio extremo a extremo en un servicio de Cloud Computing, depende directamente de la disponibilidad interna de los elementos de no formen parte del control del carrier y son responsabilidad de la TI".

En este punto, ya tenemos las bases para realizar un cálculo de disponibilidad de acuerdo a los componentes o equipos que se tengan y de las redundancias respectivas en cada elemento que compone a cada equipo individual.

¿Restaría considerar algún componente más?, la respuesta es SI. Primero, nos falta considerar la disponibilidad asociada a todos los componentes habilitadores de la red tales como cableado, respaldo de energía (UPS), circuitos eléctricos, etc. Cada componente cuenta como un elemento más en serie para el cálculo total de disponibilidad o SLA del escenario que nos encontremos evaluando. A pesar de ello, es literalmente casi imposible calcular la disponibilidad de cada uno de estos componentes de "capa física", así que para fines prácticos, estos no son considerados para el cálculo respectivo.

Segundo, hemos platicado extensamente de la disponibilidad de cada componente de la red en términos de hardware, enlaces o proveedores de servicios y componentes habilitadores o de capa física. Aunque ya cuentan con bastante robustez para el cálculo de disponibilidad o SLA los componentes contemplados, todo equipo de comunicaciones esta formado también por elementos de software (el sistema operativo de cada equipo y firmware en algunos casos más) y al presentarse bugs o corrupciones, provocarán la caída del hardware y por tanto cuentan como elementos en serie aunque no se pueda tener un MTBF tangible. Por ello, la disponibilidad del sistema operativo y firmware, debe contar como elementos en serie para el cálculo de disponibilidad de cada equipo individual. Al igual que el cálculo de disponibilidad de los componentes habilitadores de red, es muy difícil calcularlo al ser solo el fabricante el que cuente con valores de MTBF de su software derivados de estadísticas llevadas a cabo y documentadas por medio de sus centros de asistencia técnica (conocidos como TAC, Technical Assistant Center).

Ahora, ¿para que requerimos la red?, principalmente, para que sobre ella, "corran" las aplicaciones de negocio. Por tanto, las aplicaciones también tienen su SLA que debe ser considerado en el cálculo de disponibilidad para conocer como impacta el SLA hacia los usuarios de dichas aplicaciones, cuando se este calculando el SLA de ellas. Como en el caso del sistema operativo, es muy difícil (casi imposible), calcular el SLA por este concepto, así que lo omitiremos.

Brevemente, describiré algunas prácticas a considerar para contribuir en incrementar la disponibilidad o SLA de una arquitectura de tecnología:

• Preferir imágenes de sistema operativo estables vs imágenes nuevas o en espera de retroalimentación de hallazgos en operación por parte de los clientes (cada fabricante califica a sus imágenes de sistema operativo regularmente en 3 niveles: nueva imagen, imagen con parches e imagen completamente probada y parchada sin nuevos hallazgos).
• Recomendaciones básicas de redundancia de componentes en cada equipo:
• Enlaces redundantes entre capas
• Considerar redundancia de fuentes de alimentación
• Considerar redundancia en supervisoras o routing engines
• Considerar redundancia en linecards que conectan equipos entre capas de la red LAN (acceso, distribución y core) y la red del DataCenter.
• Considerar habilitar virtualización de chasis en la capa de distribución o core de la red LAN y en la capa de core del DataCenter.
• Considerar redundancia en el backplane de los switches de core de la red LAN y el core del DataCenter.
• Considerar redundancia en aplicaciones virtualizadas en cómputo diferente (blades o servers).
• Considerar respaldo de energía independiente para las fuentes principal y de respaldo de los equipos.
• Considerar redundancia en los circuitos eléctricos para las fuentes principal y de respaldo de los equipos.
• Considerar trayectorias de fibra óptica independientes para las conexión entre capas de la red LAN y la red del DataCenter.

Quisiera terminar los diferentes cálculos de alta disponibilidad que hemos venido haciendo con una reflexión, hay diferentes nivel de redundancia en los diferentes elementos que componen un equipo de comunicaciones, que pueden ser denominados con la nomenclatura 1+1, N+1, N+M, etc. ¿qué significan? el número posterior al signo de "+" indica cuando elementos redundantes se pueden colocar como redundancia a cada elemento principal, es decir, 1+1 indica que por cada elemento principal, habrá uno más redundante. Una redundancia 2+1, indica que por cada 2 elementos principales, existe un solo elemento como redundancia a ambos, etc. ¿Qué arreglo da una mayor disponibilidad (1+1 o 2+1)?, hagamos el cálculo.

Suponiendo que tenemos fuentes de alimentación con disponibilidad de 99.97% cada una de ellas, si tuviésemos un equipo que maneje redundancia 1+1, ¿cuál sería la disponibilidad de las fuentes de alimentación?. Para ello, hacemos uso del cálculo de elementos en paralelo que se detalla en la primera parte de este artículo, de la siguiente manera:

Disponibilidad fuentes en arreglo 1+1 (%) = 1 - [(1-0.9997)*(1-0.9997)] = 99.999%

Si ahora contáramos con un equipo que requiere para operar 2 fuentes de alimentación y cuenta con 1 más como redundancia (2+1) con las mismas disponibilidad individuales, la disponibilidad del arreglo de fuentes sería:

Disponibilidad de 1 fuente activa y su redundancia (elementos en paralelo) = 1 - [(1-0.9997)*(1-0.9997)]
Disponibilidad de 1 fuente activa y su redundancia (elementos en paralelo) = 99.999%

Disponibilidad fuentes en arreglo 2+1 (%) = disponibilidad de fuentes 1+1 * disponibilidad fuente
Disponibilidad fuentes en arreglo 2+1 (%) = 0.99999 * 0.9997 = 99.96%

Cuarta Conclusión: "Cuentan con mayor disponibilidad, los esquemas de redundancia 1+N (donde N es igual o mayor a 1) que los esquemas de redundancia N+1".

La alta disponibilidad como puede verse, esta en función de la cantidad de elementos en paralelo para con ello, lograr que la disponibilidad en serie nos lleve a un alto SLA o tendiente a los famosos cinco 9s. Sin embargo, el precio es un excelente indicador que puede decirnos cuanta redundancia es suficiente para un equipo o un escenario, basado en los objetivos de negocio que deberemos cumplir en último fin. La gráfica siguiente que llamo de "costo-beneficio de disponibilidad" ilustra lo anterior.

Ya sabiendo todo lo que hemos comentado, ¿Cuánta disponibilidad es la correcta de acuerdo a nuestro negocio?, el que podamos pagarla es un indicador como he indicado, pero lo que realmente nos da un segundo y el mas importante indicador al respecto desde mi punto de vista, es las afectaciones visibles hacia el exterior por una indisponibilidad, y como es inevitable en esos casos, cuando ocurre todo mundo se da cuenta. ¿A qué me refiero?, lo contestaré con preguntas, ¿cuánto representa en una mala imagen al cliente que el servicio de cobro mediante tarjetas de crédito no funcione el fin de semana de una venta especial para una tienda departamental?, ¿Cuantas cancelaciones de líneas móviles puede representar una intermitencia en el servicio de un operador de telefonía móvil?, ¿Qué sucedería si el sistema de declaraciones anuales, se encuentra indisponible en la última semana de recepción de este trámite?, ¿me explico?, la afectación a la imagen, los clientes y la ciudadanía en la general nos darán una idea para evitar caer en la tentación de ahorrarnos unos miles al inicio, que nos pueden costar millones en la operación cotidiana.

¿Pero qué creen?, de acuerdo a un estudio llevado a cabo por Gartner en 2007 y aún vigente, menciona que la principal razón por la cual una red de comunicaciones falla o "se cae" es por errores del personal de operación y soporte al momento de realizar alguna actividad de mantenimiento. ¿Cuál es la razón?, lo de "siempre", por no contar con un plan definido y previamente revisado y aprobado de cambios, por la inexistencia de un plan de contingencia por si algo no sale como se planeo, por no contar con bitácoras que nos indiquen quién hizo qué y cuando en cada equipo, por no llevar documentada toda la operación de la red, etc, etc, etc.. La lista es interminable. La siguiente figura lo muestra.

Adicionalmente, de acuerdo a Yakee Group, ratifica que la segunda razón de la caída de una red, es el error humano como se muestra a continuación.

Aún falta más...

Recursos adicionales:

• The road to five nines
• http://www.cisco.com/warp/public/437/services/rt59/documents/yankee_report.pdf

El dilema de eso que significa contar con "alta disponibilidad" en nuestras arquitecturas de tecnología (parte 1 de 3)

Es común escuchar de nuestros clientes solicitarnos que consideremos en la propuesta a desarrollar un diseño o arquitectura tecnológica con "alta disponibilidad", con sus "redundancias" o "carrier class", al estar con ellos tomando algún requerimiento de una nueva solución o una mejora a una solución ya existente. Sin embargo, la famosa frase de "alta disponibilidad" dista mucho de ser un feature o licencia más a agregar en el desglose de números de parte o BOM (Bill of Material) de la solución a proponerles. De hecho, el término en cuestión, es en mi personal punto de vista, uno de los aspectos de los cuales se habla mucho en el entorno de tecnología en general y del que menos se conoce al respecto en toda la amplitud del tema tanto por fabricantes, como por diseñadores, arquitectos de tecnología o clientes.

Este pequeño artículo, intenta dar una breve introducción al tema y ayudar al lector a tener un entendimiento sólido de las implicaciones que se derivan de hablar de una solución tecnológica con alta disponibilidad.

Si les parece, lo mejor es iniciar distinguiendo la diferencia entre disponibilidad de la solución y redundancia.      La disponibilidad es un valor cuantitativo que nos indica la cantidad de tiempo que un elemento de red (equipo) o la red en sí misma, se encontrará funcionando de manera normal, es decir, sin falla alguna. La disponibilidad se mide regularmente de manera porcentual en cifras mayores al 95%. Ejemplos: 99.98%, 99.99%, 99.999%, etc. Entre mayor sea este valor, menos probable es que el elemento o la red se encuentren en un estado de indisponibilidad o dicho de otra manera, se cuente con una "alta disponibilidad" (HA, High Availability). La mayor disponibilidad ampliamente empleada para un elemento o la red en sí misma, son los llamados cinco 9s o 99.999%.

Estos porcentajes cercanos al 100% son los que comúnmente se utilizan para firmar acuerdos de niveles de servicio entre los proveedores de servicios y los clientes (conocidos como SLAs, Service Level Agreement).

Otro forma de expresar los valores porcentuales anteriores, es trasladarlos a cifras de tiempo anualizadas, es decir, ¿cuánto tiempo de indisponibilidad tendrá como máximo un equipo o la red en sí, que cuente por ejemplo con una disponibilidad de 99.99% o cuatro 9s? La respuesta la obtenemos calculando la cantidad de minutos año (60x24x365 = 525,960 minutos al año) y aplicando el porcentaje de indisponibilidad (100%-99.99% o 1-disponibilidad) con lo cual obtenemos que un elemento/equipo o la red en sí tendrá a lo más 52.59 minutos de indisponibilidad (downtime) al año.

Si llevamos a cabo el mismo cálculo para un elemento o red con cinco 9s o 99.999%, tenemos que no debe encontrarse más de 5 minutos indisponible (caído o downtime) en el lapso de 1 año. Resumiendo la relación entre dos o más 9s vs el tiempo máximo permisible de downtime al año, tendremos:

Disponibilidad	Downtime Máximo al Año (minutos)
99%	5259
99.9%	525
99.99%	52
99.999%	5

El método empleado para el cálculo de disponibilidad, es el conocido como método de porcentajes y es el más empleado en el ámbito de telecom, sin embargo no es único, existe un método adicional conocido como método de defectos por millón (DPM, defects per million). En este artículo nos enfocaremos al primer método únicamente.

Aclaremos ahora el concepto de “redundancia”. La redundancia de una solución, está asociada a la adición de elementos dentro de la arquitectura propuesta que nos permitan cumplir la disponibilidad solicitada u objetivo (a través de considerar elementos adicionales a los principales o los elementos mínimos para que un equipo o arquitectura opere).

Para lograr una cierta disponibilidad objetivo (solicitada), se deben tomar en cuenta todos aquellos aspectos que influyen en el cumplimiento de la misma ya que hay varias consideraciones que tomar en al menos las siguientes áreas de influencia:

·         La topología de la arquitectura a proponer.

·         La redundancia de elementos (hardware) en los dispositivos de red.

·         Los mecanismos de alta disponibilidad a habilitar en los dispositivos a proponer.

·         Los mecanismos de seguridad a implementar.

·         La definición de niveles de administración por usuario y políticas asociadas.

·         La redundancia considerada en los elementos de soporte a la red (UPS, cableado, circuitos eléctricos, etc.).

·         Las estabilidad (o ausencia de bugs) en los sistemas operativos de cada uno de los elementos de la arquitectura propuesta.

Cada uno de los aspectos anteriores, los detallaré a continuación.

La topología y su influencia en la disponibilidad de red

Empecemos primero, por analizar la topología de red asociada a las diferentes soluciones tecnológicas (LAN, WAN, DC, etc.). Para ello, nos apoyaremos de la siguiente figura (cuyos círculos llamaremos indistintamente vértices, nodos o sitios de red):

La figura anterior mejor conocida en el ámbito de redes como grafo, es una representación de nodos y sus enlaces físicos de conexión entre ellos, dicho grafo, bien puede ser la topología de una red WAN, LAN o DC de algún cliente. Desde el punto de vista de teoría de grafos, hay entre varios aspectos a considerar para una adecuada definición de una topología de red, 2 de ellos que nos interesan para el tema de "alta disponibilidad" en cuestión. El primero de ellos, es lo que se conoce como hop count, es decir, se intenta que cualquier grafo o topología de red, cuente con la menor cantidad de saltos entre cualesquiera pares de puntos o nodos de la red con la intención de contar con rutas lo más cortas posibles. Así que el primer aspecto como consultores que debemos observar en las soluciones tecnológicas a proponer a nuestros clientes, es sin duda, recomendaciones de sus diferentes topologías de red con la intención de contar con grafos lo más limpios posibles. ¿En que nos afecta contar con topologías de red complejas e ineficientes desde la perspectiva de saltos entre pares de nodos?, en que los protocolos de red sean estos de capa 2 o capa 3, tardarán un mayor tiempo en converger ante la reconstrucción de su árbol de decisión de rutas y las rutas alternas, pueden llegar a ser muy ineficientes con respecto a la ruta principal (u óptima) e inclusive provocar loops. La resolución de fallas (troubleshooting), se vuelve también compleja y muy tardada cuando se requiere.

Para el grafo anterior, por ejemplo, el hop count para el tráfico del sitio 1 al sitio 6 es de 3, mientras que para el tráfico del sitio 3 al sitio 5 es de solo 2.

El siguiente aspecto a observar en la topología de red, es el conocido como grado del grafo, es decir, la cantidad de rutas alternas o enlaces con que cuenta cada sitio o nodo de la red, para conexiones hacia la siguiente capa o el exterior (posibles rutas alternas). En nuestro grafo de ejemplo, el nodo 6 tiene grado 1, los nodos 4/5/2 tienen grado 3 y los nodos 1/3 tienen grado 2.

De lo que se trata en toda red si alcanzan a observar, es que la topología de red cuente en la medida de lo posible con la menor cantidad de saltos entre pares de nodos y la mayor redundancia (grado) posible, aunque el aspecto económico siempre debe estar presente. Así pues, una red con nodos con un mayor grado, tienden a contar con mayores alternativas de comunicación ante la falla de algunas de las trayectorias principales y con ello, impactar favorablemente la disponibilidad asociada.

¿Cuánta redundancia considerar en cada elemento o dispositivo de la red?

¿Qué aspectos de alta disponibilidad debemos cuidar en los equipos a proponer?, de acuerdo al nivel de disponibilidad objetivo, se debe considerar aprovisionar redundancia en elementos tales como fuentes de alimentación, procesadoras/supervisoras/routing engines, backplane/matriz de conmutación, tarjetas/linecards, etc. donde se conectarán las interfases hacia distintas capas o sitios de la red, hasta considerar la duplicidad en los equipos o chasis con la finalidad de que la alta disponibilidad de estos componentes logre que se cumpla la disponibilidad objetivo. Pero, ¿cuánta redundancia es necesaria entonces en cada elemento? Para responder esta pregunta, tendremos que hacer uso de las matemáticas que nos permiten calcular la disponibilidad por cada elemento individual y posteriormente modelar escenarios para obtener la disponibilidad de la red en sí misma.

La disponibilidad de un elemento individual, se calcula de la siguiente manera:

Disponibilidad elemento individual (%) = MTBF / (MTBF+MTTR)

Donde:

MTBF (Mean Time Between Failures).- Tiempo medio entre fallas del elemento analizado (en horas). Es un dato que lo provee el fabricante del hardware.

MTTR (Mean Time To Repair).- Tiempo que lleva poner en operación el elemento caído una vez que falló ( en horas). Es un dato que se determina entre el cliente y quién vaya a llevar a operar dicho elemento a través de un contrato de servicios (mantenimiento, servicio administrado, tercerizado o cloud).

Ejemplo 1: consideremos que una tarjeta procesadora/routine engine/supervisora o como la llame cada fabricante, tiene un MTBF documentado por el fabricante de 516,000 horas, y el proveedor actual del contrato de mantenimiento de dicho hardware tiene firmado contractualmente, un tiempo máximo de reparación de fallas de 4hrs. La disponibilidad de dicha tarjeta se calculará como sigue:

Disponibilidad tarjeta supervisora (%) = 516,000 / (516,000+4) = 99.9992%

Ahora bien, si hubiésemos considerado 2 tarjetas supervisoras en el equipo a colocar como parte de nuestra solución, el cálculo de alta disponibilidad al contar con elementos redundantes (también llamados elementos paralelos), se lleva a cabo de la siguiente manera:

Disponibilidad elementos paralelos (%) = 1- [(1-disponibilidad elemento 1)*(1-disponibilidad elemento 2)*(1-disponibilidad elemento 3)*…(1-disponibilidad elemento “n”)]

Ejemplo 2: consideremos la misma tarjeta del ejemplo 1, con su respectiva supervisora redundante (2 supervisoras en el equipo). La disponibilidad de este arreglo en redundancia (o alta disponibilidad), sería:

Disponibilidad supervisora principal y redundante (%) = 1-[(1-0.999992)*(1-0.999992)] = 99.999999%

Como podemos observar, mediante el cálculo de disponibilidad de elementos en paralelo o redundantes, podemos obtener nuestra Primera Conclusión: "la disponibilidad de un elemento aumenta al colocar 1 ó más elementos adicionales o en redundancia al principal".

En este punto, ya sabemos cómo llevar a cabo el cálculo de disponibilidad de elementos individuales y elementos redundantes o paralelos en un dispositivo o equipo, ¿cómo calcular la disponibilidad de todo un equipo o dispositivo?, se tienen que llevar a cabo 2 pasos sencillos:

Paso 1.- Calcular la disponibilidad de todos los elementos redundantes en el equipo (supervisoras, fuentes, linecards, backplane, etc.) conforme los ejemplos 1 y 2, cuyo resultado dará un elemento individual que será la combinación de redundancias.

Paso 2.- Calcular la disponibilidad de todos los elementos del equipo (denominados elementos en serie ya que la falla de cualquiera de ellos será tomada como falla del equipo en análisis y contará para la medición de downtime máximo por año), de la siguiente manera:

Disponibilidad de un equipo o dispositivo (%) = disponibilidad elemento 1 * disponibilidad elemento 2 *…disponibilidad elemento “n”

Ejemplo 3: ahora pensemos que vamos a calcular la disponibilidad de un switch de DataCenter, en donde cuenta con las siguientes disponibilidades ya calculadas previamente en todos sus componentes:

·         Disponibilidad procesadoras (elementos en paralelo ya que el equipo cuenta con 1 principal y 1 más redundante) = 99.99%.

·         Disponibilidad fuentes (elementos en paralelo ya que el equipo cuenta con 1 principal y 1 más redundante) = 99.999%.

·         Disponibilidad linecard de puertos GE = 99.98%.

·         Disponibilidad linecard de puertos 10GE = 99.97%.

·         Disponibilidad del chasis = 99.99%

Disponibilidad del switch de DC (%) = 0.9999*0.99999*0.9998*0.9997*0.9999 = 99.929%

Segunda Conclusión: "La disponibilidad de un equipo o escenario es afectado por la baja disponibilidad de alguno de los elementos que lo componen".

Nota.- Hay que ser muy cuidadosos al momento de obtener los datos del MTBF de cada componente ya que regularmente los fabricantes solo publican en sus sitios Web los valores para los chasis en sus hojas de datos (datasheets). Recordemos que tenemos que obtener los valores de MTBF de cada componente individual del equipo.

Ya sabiendo como calcular la disponibilidad de un dispositivo completo, el siguiente paso, sería calcular la disponibilidad de todos los componentes que formarán parte de la arquitectura tecnológica a proponer (switches, ruteadores, servidores, firewalls, IPS/IDP, puntos de acceso, teléfonos, equipos de video, etc.), llegando a una tabla resumen como la siguiente:

Dispositivo	Disponibilidad
Switch A	99.98%
Router C	99.97%
Server	99.9%
Firewall	99.96%

¿Ya sabiendo la disponibilidad de todos los componentes de la arquitectura propuesta, que más restaría?..Continuará…

Introducción a mejores prácticas para el diseño de redes de campus (LAN Switching)

Uno de los bloques funcionales más críticos en el ámbito de redes, es la red de campus o las redes LAN. Existen sin embargo, varias omisiones que se llevan a cabo en las reglas básicas, mejores prácticas, recomendaciones o como queramos llamarlas al momento de planear y diseñar esta tecnología. Este breve artículo intenta dar un overview muy práctico al lector, para tener presentes los aspectos mínimos a considerar en el diseño de redes de campus.

Empecemos por describir las arquitecturas más comunes de las que echamos mano para un diseño de redes LAN.

La arquitectura más básica, es la que denominaré de "capa única", que consiste en un único cuarto de comunicaciones donde se alojan todos los servicios de TI (switches, ruteadores, servidores, acometidas de enlaces WAN, Internet, PSTN; etc.). Las funciones de capa 3 en este escenario, son llevadas a cabo por el ruteador(es) con que se cuente (ruteo entre VLANs, ruteo hacia la WAN, Internet, etc) y el switch o switches solo utilizan funciones de capa 2. La figura siguiente muestra esta arquitectura.

La siguiente arquitectura típica y la más utilizada para el diseño de redes LAN, es la arquitectura denominada por diferentes fabricantes, como arquitectura LAN de 2 capas. Las 2 capas son denominadas capa de acceso y capa colapsada de core/distribución respectivamente. En este escenario, la capa de core lleva a cabo las funciones de capa 3 así como mayormente el manejo de políticas (QoS, seguridad, multicast, etc.) y la capa de acceso tradicionalmente lleva a cabo funciones de capa 2 únicamente, aunque la tendencia en este sentido es que toda la red LAN se encuentre operando en capa 3, con la intención de contar con mayor disponibilidad de esta ya que la convergencia en capa 3 ya se ha probado que es más rápida ante una falla que la convergencia en capa 2. La figura siguiente muestra esta arquitectura.

Una de las variantes a esta arquitectura, es cuando con la intención de incrementar la disponibilidad de la red LAN, colocamos como arquitectos 2 switches LAN de core y con ello, enlaces redundantes entre la capa de acceso y core como se muestra a continuación. Los puertos utilizados en los switches LAN, para la conexión física entre capas de una red LAN (acceso y core en este caso), se denominan puertos o interfases de uplink. Los puertos de uplink se recomienda que sean puertos en interfases de fibra óptica (multimodo para distancias menores a 300m y monomodo para distancias mayores regularmente) ya sean a 1 Gbps, 10 Gbps, 40 Gbps o 100 Gbps; y no sean tomados de los puertos de acceso o usuario (que son del tipo 10/100Base T o 10/100/1000Base T, es decir en UTP con interfases RJ45). Tenemos entonces en cada switch, puertos o interfases que tienen como finalidad las conexiones de uplink (entre capas), y puertos o interfases para brindar el acceso a la red de todos los dispositivos que nos encontramos regularmente en una organización de TI por medio de las tarjetas de red o NIC de ellos (PCs, impresoras, acess points, cámaras de videovigilancia, controles de acceso en puertas, teléfonos IP, equipos de videoconferencia, etc).

Como se observa en la figura anterior, se debe realizar una conexión al menos con 2 interfases entre los switches de core agregando dichos enlaces mediante el estándar 802.3ad con la intención de ser vistos lógicamente como un solo puerto físico (la elipse indica esta agregación física o link aggregation).

La tercera y última arquitectura de red LAN, esta pensada en ser utilizada para redes con miles de usuarios, un campus en forma, donde se tienen múltiples edificios e IDFs en cada uno. En esta arquitectura contamos con la capa de acceso que puede estar operando en capa 2 o capa 3, una capa siguiente denominada capa de distribución (que debe contar con al menos 2 equipos) y una capa de core que consiste como en el caso de arquitectura de 2 capas, de 2 equipos interconectados entre ellos como ya explicamos. Los switches de distribución regularmente no se interconectan entre ellos como en el caso de los switches de core ya que la única razón para llevarlo a cabo, es cuando se configura la sumarización de rutas y esto prácticamente no se configura en las redes de los clientes. Al igual que en la arquitectura anterior, las conexiones de uplink se llevan a cabo preferentemente mediante interfases en fibra óptica. La figura siguiente muestra esta arquitectura.

Puede observarse, que es inherente a esta arquitectura, la redundancia en enlaces entre capas y en los equipos de las capas de distribución y core.

Desde el punto de vista de cableado, a la ubicación del cuarto de comunicaciones principal donde se encuentran los equipos switches LAN de core, se conoce como MDF. Las ubicaciones de los cuartos de comunicaciones donde se encuentran los switches LAN de acceso, se denominan IDFs. En el caso de tratarse de una arquitectura de 3 capas, podríamos denominar a la ubicación de los switches LAN de distribución como IDFs primarios y a la ubicación de los switches LAN de acceso como IDFs secundarios.

En este punto quisiera detallar algunos aspectos relevantes a tener en cuenta:

• El primero, tienen que ver con la forma en como proveer las cantidades de puertos que se requieren por IDF.

• Tenemos 2 opciones para aprovisionar las cantidades de puertos requeridos, la primera, considerar un switch LAN modular con tantas tarjetas de interfases (puertos) como dispositivos se tendrán en cada IDF. La segunda, colocar tantos switches LAN de puertos fijos (regularmente de 8, 12, 24 o 48 puertos) como dispositivos se tendrán en cada IDF e interconectarlos mediante una configuración llamada "apilamiento" o "stacking". El apilamiento consiste esencialmente, en que todos los switches que formen de una pila, lógicamente parezcan 1 solo, con lo cual solo cuentan con 1 archivo de configuración y un único punto desde el cual se realiza toda la configuración de los switches de la pila en vez de llevarlo a cabo uno a uno. La conexión física entre ellos se lleva cabo mediante puertos especiales de apilamiento que no son ni puertos de uplink, ni puertos de conexión de dispositivos o puertos de acceso. Se pueden apilar tantos switches LAN por pila de acuerdo a la arquitectura de cada fabricante (8, 9 o 10 son cantidades comunes en los fabricantes más reconocidos). La conexión de cada pila a la capa de core se realiza colocando puertos de uplink en cualquiera de los switches que son miembros de la pila.

• El segundo, tiene que ver con aquello a lo que nos referimos cuando mencionamos que una capa de la arquitectura de LAN es capa 2 o capa 3 y cuando se debe considerar una u otra.

• Cuando mencionamos que un dispositivo o en nuestro caso, que una capa de la arquitectura de red LAN opera en capa 2, nos referimos a que en los equipos de la capa de acceso se configurarán protocolos que operan en la capa 2 de acuerdo al modelo de referencia OSI como spanning tree (STP) que tiene años en desuso, múltiples instancias de spanning tree 802.1s, rapid spanning tree 802.1w, VLANs 802.1Q, marcado de tráfico para manejo de QoS 802.1p, etc.. Consecuentemente, cuando hablamos que un dispositivo o una capa en la arquitectura de red LAN, opera en capa 3, nos referimos a que se configurarán protocolos que operan en la capa 3 (protocolos de ruteo principalmente) de acuerdo al modelo de referencia OSI como OSPF (regularmente) y en algunos casos EIGRP (que es propietario de la marca Cisco). Tradicionalmente, la capa de acceso ha sido provista con protocolos de capa 2, aunque hay una fuerte tendencia para que esta capa cambie a funciones de capa 3 para mejorar los tiempos de convergencia ante la falla de comunicación hacia su capa inmediata superior.

• ¿Quién determina la cantidad de IDFs y su ubicación dentro de la red LAN?, bueno esto es llevado a cabo por el cliente y el diseñador de cableado de acuerdo a la ubicación física que habrá de nodos de red considerando las distancias máximas permitidas por ethernet (5m para el patch cord del switch ubicado en cada rack o gabinete en los IDFs al panel que se encuentra en el mismo rack o gabinete, 90m de distancia del IDF a cada roseta y 5m de cada roseta a la conexión de cada dispositivo de red). Con esta información se intentará definir la menor cantidad de IDFs posibles con los cuales se puedan ofrecer los servicios de conectividad requeridos.

• ¿Quién determina la ubicación del MDF?, el cliente con ayuda de los diseñadores de cableado tomando en consideración los requerimientos de espacio, alimentación eléctrica, aire acondicionado, tierras físicas, acometidas de los enlaces de los operadores o proveedores de servicios WAN, Internet y PSTN.

• ¿Cuántos enlaces y de qué capacidad se deben contemplar para la conexión física entre cada IDF y el MDF de la red (capa de acceso y el core)?, para contestar esta pregunta me apoyaré en la figura de arquitectura de 3 capas anterior. Una regla de diseño menciona que por cada 20 puertos o servicios de red con que se cuente en un IDF en particular, debemos considerar al menos 1 enlace de uplink a la capa de distribución de la misma capacidad (con lo cual tenemos una sobresuscripción 20:1). Es decir, si el IDF 3 tuviese switches por 180 puertos 10/100 por ejemplo, requeriríamos 9 puertos de esta capacidad o 1 puerto a 1GE entre el IDF 3 y el switch de distribución 1 y otro puerto de esta capacidad entre el mismo IDF 3 y el switch de distribución 2 (recordemos que los enlaces deben ser de la misma capacidad). Aplicando esta sencilla regla, calculamos la cantidad de enlaces necesarios y su capacidad respectiva (1GE, 10GE, 40GE o 100GE) entre la capa de acceso y la capa de distribución. De forma similar, calculamos la cantidad y capacidad de enlaces entre la capa de distribución y core, ahora aplicando la regla de sobresuscripción de 4:1, es decir, por cada 4 enlaces provenientes de las conexiones a la capa de acceso en un switch de distribución, debemos considera al menos 1 enlace de la misma capacidad hacia la capa de core. Si por ejemplo vemos el caso del switch de distribución 2, este equipo esta recibiendo 5 enlaces de la capa de acceso (1 por IDF), con lo cual requerimos enlazar este equipo con el switch de core 1 con 2 puertos de esta misma capacidad y con el switch de core 2, también con 2 enlaces de la misma capacidad. Recordemos que cuando enlacemos dos equipos con más de un puerto físico, es muy recomendable habilitar agregación de enlaces o 802.3ad para agrupar dichas interfases como una sola interfaz lógica. En el caso de tratarse de una arquitectura de 2 capas, solo se aplica la regla del 20:1 ya que la capa de distribución se encuentra colapsada con la capa de core en un solo equipo. Si pueden observar, una rápida receta de cocina a utilizar con el cuidado respectivo, es que si tenemos puertos de acceso del tipo 10/100Base T, los enlaces de uplink entre capas serán en Gigabit Ethernet, sin embargo, si los puertos de red en la capa de acceso son del tipo 10/100/1000Base T, requeriremos puertos de uplink entre capas, del tipo 10 Gigabit Ethernet. Al haber una sobresuscripción inherente al diseño basado en mejores prácticas para el cálculo de la cantidad y capacidad de los enlaces de uplink entre capas, se debe contemplar que las tarjetas (linecards) utilizadas en cada equipo para dichas conexiones de uplink, no cuenten con sobresuscripción en su conexión al backplane del equipo en donde se encontrarán alojadas (sobresuscripción 1:1) ya que esto afectaría a la estimación inicial de sobresuscripción llevada a cabo por el arquitecto.

• ¿Qué tipo de cableado se debe considerar tanto para las conexiones en fibra óptica como para los servicios en UTP?, para el caso de las conexiones de uplink (de la capa de acceso a distribución y de la capa de distribución al core) como ya hemos mencionado, se requiere fibra óptica multimodo para interiores de edificios o fibra óptica monomodo cuando hablamos de distancias superiores a 300m como en el caso de conexión entre edificios de un campus. La fibra multimodo que hoy en día se esta utilizando para nuevas implementaciones, es la conocida como fibra tipo OM3 y recientemente se encuentra comercializando fibra multimodo del tipo OM4. Para el caso del cableado UTP, actualmente se encuentran implementando los clientes cableado categoría 6, 6A ó 7.
• ¿Qué tipo de interfases para fibra óptica Gigabit Ethernet o 10 Gigabit Ethernet debo considerar?, esto depende del tipo de fibra óptica instala entre los IDFs y el MDF y la distancia entre estos cuartos de comunicación. Se pueden revisar tablas de especificaciones como las siguientes que aplica a cualquier equipo de cualquier fabricante, para determinar las interfases correctas (se debe revisar cuales de las interfases señaladas en estos documentos son soportadas por el equipo/fabricante que se debe utilizar como solución).

http://www.cisco.com/en/US/prod/collateral/modules/ps5455/ps6577/product_data_sheet0900aecd8033f885.html

http://www.cisco.com/en/US/prod/collateral/modules/ps5455/data_sheet_c78-455693.html

• ¿Adicionalmente a los enlaces de uplink de la capa de acceso, qué mas elementos se conectan en la capa de core?, en la capa de core (dentro del MDF), se conectan también los ruteadores para la salida a la red WAN (en caso de existir), la salida a Internet y los gateways de voz para la salida a la PSTN. También se conectan los servidores en caso de ser pocos estos y todo el bloque de DataCenter cuando existe (recordemos que una arquitectura completa de DC involucra múltiples capas como el caso de la arquitectura de red LAN). En el caso de existir el bloque de DC en forma, será en este donde se conecten todos los servidores y appliances de propósito específico que requerimos por las diversas tecnologías de redes (seguridad, comunicaciones unificadas, Wireless LAN, etc.). La figura siguiente ilustra las conexión física para las conexiones externas a la red LAN.

Ya una vez hecho lo anterior, ¿nos faltaría considera algo más en nuestro rol de arquitectos?, yo creo que sí, al menos 2 cosas:

• Qué la solución que estemos pensando implementar, pueda cumplir las metas de la TI y del negocio en el largo plazo.
• Los switches a colocar en la capa de acceso soporten: uplinks en 10GE, 40GE ó 100GE de acuerdo a las expectativas de crecimiento hacia los siguientes 3, 5 o más años; variantes de PoE (Power over Ethernet) al tradicional 802.3af que únicamente puede entregar 15.4W por puerto a diferencia de los 30W definidos en 802.3at y los 60W por puerto que algunos fabricantes llaman PoE universal; el que se pueda habilitar IPv6 que tarde o temprano será una realidad.
• Los switches a colocar en las capas de distribución y/o core, soporten los mecanismos aplicables definidos para la capa de acceso y además: que puedan contar con tarjetas de alta densidad de interfases de alta velocidad sin sobresuscripción (10GE, 40GE ó 100GE) en su roadmap, ya que serán estos los responsables de la agregación de los IDFs de la capa de acceso (este punto es muy relevante ya que nos encontramos en este momento en una transición de los diferentes fabricantes de redes, de sus plataformas de switching y es probable que no todas ellas vayan a cumplir este punto y más bien vendrán nuevos chasis o equipos de la misma familia o familias diferentes que si estén preparados para este requerimiento); soporten mecanismos de switcheo distribuido para con ello evitar que el equipo soporte una baja cantidad de paquetes por segundo (pps) que es un factor clave en los switches LAN.
• El cableado debe soportar las tasas de transmisión futuras (10GE, 40GE y 100GE) en el caso de la fibra óptica a instalar, por lo cual debemos observar si la fibra óptica multimodo a instalar será OM3 u OM4 conforme al crecimiento de tráfico esperado hacia los siguientes años. En lo que respecta al cableado horizontal (UTP), evaluar cual categoría 6, 6A, 7 ó 7A es la correcta de acuerdo al crecimiento de tráfico en la capa de acceso.
• ¿Cuánta redundancia debemos considerar al llevar a cabo una arquitectura de tecnología?, la respuesta esta desde mi personal punto de vista en el impacto al negocio que puede provocar la indisponibilidad de la red. ¿Cuanto daña la imagen de un banco que lleguemos a una sucursal o cajero y no haya servicio?, ¿qué implicaciones tiene que la red de instituciones electorales falle cuando se encuentran en plena jornada electoral?, como estos ejemplos, podemos seguir y seguir... es por ello, que cuando pensemos como arquitectos o responsables de la TI que un componente de la arquitectura esta de más, lo analicemos dos veces antes de decidir prescindir de él.
• Los aspectos mínimos de redundancia a evaluar, para su implementación.
• Siempre como arquitectos debemos cuidar proveer la redundancia suficiente en la arquitectura a desarrollar como: redundancia en los módulos de procesamiento/routing engines, redundancia en el backplane del equipo, redundancia en las fuentes de alimentación, configuración de mecanismos lógicos que contribuyan a una rápida recuperación del equipo ante una falla de alguno de sus componentes, tales como actualización del sistema operativo en caliente (ISSU, In Service Software Upgrade), actualización modular del sistema operativo (solo módulos corruptos y no toda la imagen de sistema operativo preferentemente), mecanismos de permitan el seguir haciendo "forwarding" de paquetes ante la falla de su procesadora principal/routing engine (non stop active routing o non stop forwarding), que puedan regresar a la configuración anterior del equipo si ante una actualización de configuración, esta falla o provoca intermitencias del equipo (rollback de versiones).
• En lo que respecta a los elementos habilitadores del servicio o como a veces los llamamos "los componentes de capa física", debemos cuidar: implementar la categoría correcta de cableado de acuerdo a los servicios que pretendemos colocar en la capa de acceso (para servicios 10/100 PoE, categoría 5e como mínimo conforme ANSI/TIA/EIA-568-B.1; para servicios 10/100/100 PoE, categoría 6 como mínimo conforme ANSI/TIA/EIA-568-B.2-1;  para servicios 10GE Base T, categoría 6A, 7 o 7A como mínimo), asegurar el buen funcionamiento de las tierras físicas conforme a ANSI/TIA/EIA-607, colocar circuitos eléctricos diferentes para la conexión de fuentes principales y fuentes redundantes de los equipos, colocar respaldo de energía (UPS) e independiente para las fuentes principales y redundantes de los equipos, colocar tendidos de fibra óptica por trayectorias diferentes entre el MDF y los distintos IDFs cuando se planea un diseño con enlaces redundantes de uplink y alimentar las fuentes de alimentación a su voltaje correcto. Es más común de lo que puedan creer que se cometan graves errores al energizar un equipo y más común, que todas las partes desconozcan las implicaciones que ello conlleva. Como "receta de cocina", podemos mencionar que todo equipo (de cualquier tecnología y cualquier marca) con fuentes de alimentación de más de 1400W requiere ser alimentado a 220VAC, y en la mayoría de los casos, en los sites (cuartos de comunicaciones) solo se cuenta con tomas a 110VAC. ¿Qué sucede ingenieros si reducimos el voltaje a la mitad (alimentar a 110VAC en vez de 220VAC)?, pues sencillo, la ley de ohm nos lo dice (P=IV), exacto! la potencia se reduce a la mitad también!. Así que, NUNCA lo hagan.

No menos importante es que la asignación de direccionamiento IP a emplear este apegado al RFC 1918, en el caso de activarse servicios de syslog, apegarse al RFC 5424 y para el caso de aplicación de políticas de calidad de servicio, apegarse a las recomendaciones del RFC 5865.

Finalmente, comentaré que en los casos en los cuales se propondrá como parte de la arquitectura de LAN a diseñar, redundancia en los equipos de la capa de distribución y/o core, se recomienda ampliamente llevar a cabo la virtualización de chasis, que permite que cada par de chasis físicos sean vistos como un solo chasis virtual hacia las capas o dispositivos conectados a él. La razón de llevar a cabo esta virtualización es con fines de mejorar los tiempos de convergencia ante la necesidad de recuperación debida a una falla.

Espero que estos simples lineamientos les sean de utilidad, les dejo documentos mucho más completos para que puedan profundizar en el tema.

Recursos adicionales:

http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/Borderless_Campus_Network_1.0/Borderless_Campus_1.0_Design_Guide.html

http://www.juniper.net/us/en/community/junos/training-certification/day-one/fabric-switching-tech-series/config-ex-series/