CLUSTERS HA LINUX Clusters de Alta Disponibilidad

Transcripción

1 CLUSTERS HA LINUX Clusters de Alta Disponibilidad Yezid Camilo Guerrero Angulo Javier Mauricio Ortiz December 11, 2013 Contents 1 Introducción 2 2 Marco Teórico Qué es un cluster? Cluster de Alta Disponibilidad HA Configuraciones de Alta Disponibilidad Arquitectura Cluster Linux de Alta Disponibilidad Funcionamiento Cluster Linux de Alta Disponibilidad Soluciones multinodos Software Cluster HA en Linux Objetivo 15 4 Desarrollo Paso a Paso - HowTo Alta Disponibilidad con Heartbeat Recomendaciones 21 6 Conclusiones 22 1

2 1 Introducción CLUSTERS HA LINUX Clusters de Alta Disponibilidad Para conseguir redundancia y protección contra fallos de un sistema, la primera de las medidas que se suelen tomar es replicar sus componentes hardware más críticos. Por ejemplo en el caso de un servidor se emplean configuraciones de discos en RAID (Redundant Array Inexpensive Disks - sistema de almacenamiento de datos que usa múltiples unidades de almacenamiento de datos), fuentes de alimentación redundantes, varias interfaces de red en bonding (Unión de varias tarjetas de red independientes), etc. Y el mismo concepto de redundancia se aplica también para el resto de componentes como la electrónica de red o el sistema eléctrico. Estas medidas indudablemente aumentan el nivel de disponibilidad de un sistema, pero para conseguir un nivel aún más alto, se suelen utilizar configuraciones avanzadas de hardware y software como son los clusters de Alta Disponibilidad (Clusters HA). En la actualidad es de gran importancia para las instituciones, empresas y el negocio tener los servicios, aplicativos y páginas web disponibles siempre o casi siempre, y no sólo por el tema económico, sino también por imagen. Pensemos que si a la hora de intentar acceder a una determinada página web, un alto porcentaje de las veces no se encuentra disponible y en términos profesionales genera cierta inseguridad de cómo manejan sus aplicativos, y en otros términos se perderá un considerable número de visitas e interés por parte de los usuarios. Si hay un campo en donde Linux es unos de los principales titulares indiscutibles o se ha visto que se destaca, es en el clustering, la capacidad de unir varias máquinas virtuales o físicas para dar servicio a la vez de forma que se balancean recursos para evitar sobrecargas de algunos servidores y en casos de que alguno falle y no pueda ofrecerlo. Esto es algo transparente al usuario final, pues se cuenta con una dirección virtual en donde se accede a todo el servicio del cluster y luego los nodos que son los que realmente proporcionarán el servicio. Por lo tanto y conociendo la importancia de un cluster; en este documento encontraremos la definición del mismo, sus servicios, pero principalmente nos enfocaremos en cluster HA, su arquitectura, tecnologías utilizadas, tipos de cluster HA y sus respectivas aplicaciones, etc. AL final se dará a conocer un ejemplo de configuración básica de un cluster Heartbeat en Linux, que suele ser muy utilizado en producción a nivel profesional. 2

3 2 Marco Teórico 2.1 Qué es un cluster? Un cluster, consiste en un grupo de nodos entre sí unidos mediante una red de alta velocidad generalmente redes de área local, que interactúan como una sola máquina. En caso que un nodo deje de funcionar tomaría el control el segundo nodo, reduciendo así considerablemente la tolerancia a fallos y caídas de servicio. Un cluster podría servir perfectamente en el caso de un problema de hardware, los usuarios tendrían igualmente servicio ya que uno de los nodos tomaría el control como máquina primaria. La tecnología de clusteres ha evolucionado en apoyo de actividades que van desde aplicaciones de supercómputo y software de misiones críticas, servidores web y comercio electrónico, hasta bases de datos de alto rendimiento, entre otros usos. Los clusteres son usualmente empleados para mejorar el rendimiento y/o la disponibilidad por encima de la que es provista por un solo computador típicamente siendo más económico que computadores individuales de rapidez y disponibilidad comparables. De un cluster se espera que presente combinaciones de los siguientes servicios: Alto rendimiento Alta disponibilidad Balanceo de carga Escalabilidad La construcción de los computadores del cluster es más fácil y económica debido a su flexibilidad, así: Cluster homogéneo: Todos los nodos se basan en la misma configuración de hardware y sistema operativo. Cluster semihomogéneo: Diferente rendimiento pero con arquitecturas y sistemas operativos similares. Cluster heterogéneo: Diferente hardware y sistema operativo. Se recomiendan las configuraciones de hardware homogéneos (nodos con especificaciones similares en términos de sockets de CPU, núcleos, la memoria, etc.) Para que un cluster funcione como tal, no basta solo con conectar entre sí los ordenadores, sino que es necesario proveer un sistema de manejo del 3

4 cluster, el cual se encargue de interactuar con el usuario y los procesos que corren en él para optimizar el funcionamiento. 2.2 Cluster de Alta Disponibilidad HA Un cluster de alta disponibilidad es un conjunto de dos o más servidores, que se caracteriza por compartir el sistema de almacenamiento, y porqué están constantemente monitorizándose entre sí. Si se produce un fallo del hardware o de los servicios de alguno de las máquinas que forman el cluster, el software de alta disponibilidad es capaz de rearrancar automáticamente los servicios que han fallado en cualquiera de los otros equipos del cluster. Y cuando el servidor que ha fallado se recupera, los servicios se migran de nuevo a la máquina original. Esta capacidad de los clusters de restablecer en pocos segundos un servicio, manteniendo la integridad de los datos, permite que en muchos casos los usuarios no tengan porqué notar que se ha producido un problema. Cuando un problema de este tipo, se presenta en un sistema sin cluster, podría dejarles sin servicio durante horas. La utilización de clusters no solo es beneficiosa para caídas de servicio no programadas, sino que también es útil en paradas de sistema programadas como puede ser un mantenimiento hardware o una actualización software. En general las razones para implementar un cluster de alta disponibilidad son: Aumentar la disponibilidad Mejorar el rendimiento Escalabilidad Tolerancia a fallos Recuperación ante fallos en tiempo aceptable Reducir costes Consolidar servidores Consolidar el almacenamiento 4

5 2.3 Configuraciones de Alta Disponibilidad Las configuraciones más comunes en entornos de clusters de alta disponibilidad son: Configuración Activo/Activo: En una configuración activo/activo, todos los servidores del cluster pueden ejecutar los mismos recursos simultáneamente. Es decir, los servidores poseen los mismos recursos y pueden acceder a estos independientemente de los otros servidores del cluster. Si un nodo del sistema falla y deja de estar disponible, sus recursos siguen estando accesibles a través de los otros servidores del cluster. La ventaja principal de esta configuración es que los servidores en el cluster son más eficientes ya que pueden trabajar todos a la vez (aumento de potencia con el aumento de nodos). Sin embargo, cuando uno de los servidores deja de estar accesible, su carga de trabajo pasa a los nodos restantes, lo que produce una degradación del nivel global de servicio ofrecido a los usuarios. Desventaja: No todos los servicios son clusterizables y su configuración es complicada. En la siguiente figura se muestra como ambos servidores están activos, proporcionando un mismo servicio a los diferentes usuarios. Los clientes acceden al servicio o recursos de forma transparente y no tienen conocimiento de la existencia de varios servidores formando un cluster. 5

6 Configuración Activo/Pasivo:Una configuración activo/pasivo, consiste solamente en un nodo que da servicio y los otros nodos son capaces de acceder a esos recursos, pero no los activan hasta que el servidor principal este inactivo. Las ventajas de la configuración activo/pasivo son que no hay degradación de servicio y que los servicios solo se reinician cuando el servidor activo deja de responder y es de configuracin sencilla. Sin embargo, una desventaja de esta configuración es que los servidores pasivos no proporcionan ningún tipo de recurso mientras están en espera, haciendo que la solución sea menos eficiente que el cluster de tipo activo/activo. Otra desventaja es que los sistemas tardan un tiempo en migrar los recursos (failover) al nodo en espera. 6

7 2.4 Arquitectura Cluster Linux de Alta Disponibilidad Linux es conocido como un sistema operativo estable. Sin embargo, una configuración cliente/servidor Linux puede tener varios puntos de falla, incluyendo el hardware del servidor, los componentes de red y las aplicaciones basadas en servidor. A medida que más administradores eligen Linux para aplicaciones críticas, la demanda de clusters alta disponibilidad (HA) para la plataforma Linux es cada vez mayor. En respuesta, varios distribuidores de Linux han diseado e implementado soluciones de Alta Disponibilidad empaquetados en sus productos, y numerosos complementos están disponibles ahora. La disponibilidad de los sistemas se clasifica con la regla de los 9s: Almacenamiento: Los datos son críticos ya que sin ellos no se puede ofrecer el servicio. Existen dos técnicas para garantizar la alta disponibilidad en los sistemas de almacenamiento: - Sistemas de almacenamiento externo. Ventajas: Altamente escalable. Rapidez, hasta 4 Gb/s. Inconvenientes: Precio. Requiere personal especializado. 7

8 - Replicación de datos: Ventajas: Barato. Inconvenientes: Poco escalable. Lentitud. La replicación de datos se puede hacer utilizando slony que es un sistema de maestro a varios esclavos de replicación para PostgreSQL apoyo en cascada, por ejemplo un nodo puede alimentar a otro nodo que se alimenta de otro nodo y así sucesivamente, y de conmutación por error. 8

9 2.5 Funcionamiento Cluster Linux de Alta Disponibilidad En un cluster de alta disponibilidad, el software de cluster realiza dos funciones fundamentales. Por un lado intercomunica entre sí todos los nodos, monitorizando continuamente su estado y detectando fallos. Y por otro lado administra los servicios ofrecidos por el cluster, teniendo la capacidad de migrar dichos servicios entre diferentes servidores físicos como respuesta a un fallo. A continuacin se describen los elementos y conceptos básicos en el funcionamiento del cluster: - Recurso y grupos de recursos: Tradicionalmente se entiende como servicio a un conjunto de procesos que se ejecutan en un momento dado sobre un servidor y sistema operativo. Este último provee a los procesos, los recursos necesarios para realizar su tarea: sistema de ficheros, interfaces de red, tiempo de cpu, memoria, etc. En un cluster de alta disponibilidad, el software de cluster, abstrae e independiza a los servicios de un host concreto. Posibilitando que estos se desplacen entre diferentes servidores de forma trasparente para la aplicación o los usuarios. El software de cluster permite definir grupos de recursos, que son todos aquellos recursos necesarios por el servicio. Estos recursos serán los scripts de arranque del servicio, un sistema de ficheros, una direccin IP, etc. 9

10 - Intercomunicación: El software de cluster gestiona servicios y recursos en los nodos. Pero además, tiene que mantener continuamente entre estos una visión global de la configuración y estado del cluster. De esta forma, ante el fallo de un nodo, el resto conoce que servicios se deben restablecer. Ya que la comunicación entre los nodos del cluster es crucial para el funcionamiento de este, es habitual utilizar un canal específico como una red IP independiente o una conexión serie, que no se pueda ver afectada por problemas de seguridad o rendimiento. - Heartbeat: El software de cluster conoce en todo momento la disponibilidad de los equipos físicos, gracias a la técnica de heartbeat. El funcionamiento es sencillo, cada nodo informa periódicamente de su existencia enviando al resto una senal de vida. - Escenario Split-Brain: Falla la comunicacin Heartbeat entre dos grupos diferentes de nodos. En un escenario split-brain, más de un servidor o aplicación pertenecientes a un mismo cluster intentan acceder a los mismos recursos, lo que puede causar danos a dichos recursos. Este escenario ocurre cuando cada servidor en el cluster cree que los otros servidores han fallado e intenta activar y utilizar dichos recursos. - Monitorización de Recursos (Resource Monitoring): Ciertas soluciones de clustering HA permiten no solo monitorizar si un host físico está disponible, también pueden realizar seguimientos a nivel de recursos o servicios y detectar el fallo de estos. El administrador puede configurar la periodicidad de estos monitoreos así como las acciones a llevar a cabo en caso de fallo. - Reiniciar recursos: Cuando un recurso falla, la primera medida que toman las soluciones de cluster es intentar reiniciar dicho recurso en el mismo nodo. Lo que supone detener una aplicación o liberar un recurso y posteriormente volverlo a activar. Algunas implementaciones no permiten reiniciar un único recurso, y lo que realizan es un reinicio completo de todo un grupo de recursos (servicio). Esto puede llegar a demorar bastante para servicios como las bases de datos. - Migración de Recursos (Failover): Cuando un nodo ya no está disponible, o cuando un recurso fallido no se puede reiniciar satisfactoriamente en un nodo, el software de cluster reacciona migrando el recurso o grupo de recursos a otro nodo disponible en el cluster. 10

11 De este modo el tiempo de inactividad por el posible fallo es mínimo, y el cluster seguirá proporcionando el correspondiente servicio. - Dependencia entre recursos: Habitualmente para que el cluster proporcione un servicio, son necesarios no solo un recurso si no varios (IP virtual, sistema de ficheros, proceso), lo que se conoce como grupo de recursos. Cuando se arranca o detiene un servicio, sus recursos tienen que activarse en el orden apropiado ya que unos dependen de otros. El software de cluster tiene que permitir definir estas dependencias entre recursos así como entre grupos. - Preferencia de Nodos (Resource Stickiness): En configuraciones de cluster con múltiples nodos, es común distribuir los servicios a proporcionar entre los diferentes servidores. Además puede que los servidores tengan 11

12 características hardware diferentes (cpu, memoria ram) y nos interese que, para un estado ideal del cluster, determinados servicios se ejecuten siempre en un determinado servidor. Este comportamiento se define mediante la preferencia de nodo en la definición de cada recurso. - Comunicación con otros sistemas: El cluster tiene que monitorizar no solo que un servidor y sus servicios están activos, también debe de comprobar que, de cara a los usuarios, dicho servidor no queda desconectado de la red por el fallo de un latiguillo, switch, etc. Por lo tanto el software de cluster debe comprobar que los nodos son alcanzables. Un método simple para conseguirlo, es verificar que cada nodo tiene accesible el router o puerta de enlace de la red de usuarios. - Fencing: En los clusters HA existe una situación donde un nodo deja de funcionar correctamente pero todava sigue levantado, accediendo a ciertos recursos y respondiendo peticiones. Para evitar que el nodo corrompa recursos o responda con peticiones, los clusters lo solucionan utilizando una técnica llamada Fencing. La función principal del Fencing es hacerle saber a dicho nodo que está funcionando en mal estado, retirarle sus recursos asignados para que los atiendan otros nodos, y dejarlo en un estado inactivo. Linux HA soporta: STONITH (Shoot The Other Node In The Head): es un servicio que sirve para garantizar que un nodo está realmente muerto en situaciones de clusters con servicios críticos en cuanto a integridad de datos. Sistemas Self-Fencing (Sistemas que aseguran acceso exclusivo a un recurso (ServerRAID de IBM)) para resource fencing: Es un sistema mediante el cual podemos decirle a un servidor que maneje varios discos como si se tratasen de uno sólo, o que vaya duplicando la información de un disco en otro para que al descomponerse uno pueda seguir funcionando con la información grabada en otro. - Quorum: Para evitar que se produzca un escenario de Split-Brain, algunas implementaciones de cluster HA introducen un canal de comunicación adicional que se emplea para determinar exactamente que nodos están disponibles en el cluster y cuáles no. Tradicionalmente se implementa utilizando los llamados quorum devices, que habitualmente son un volumen 12

13 de almacenamiento compartido exclusivo (disk heart beating). Uno de los sistemas más comunes de Quorum es el voto. Solo la división con más nodos puede ejecutar el cluster. Esto no funciona muy bien para dos nodos. Otro sistema de Quorum es el acceso a un recurso exclusivo, el que llegue después, desiste y cede los servicios. - SPOFs (single point of failure): Elemento del sistema que en caso de fallo puede dejar todo el sistema inutilizado. Un buen diseno elimina todos los SPOFs. Un SPOF puede ser un componente de hardware, software o eléctrico. Para garantizar la inexistencia de un SPOF en un sistema, todos sus componentes suelen ser redundados, conformando así un sistema de alta disponibilidad, que garantiza el correcto funcionamiento aún en caso de que alguno de sus componentes falle. 2.6 Soluciones multinodos Aunque las configuraciones de cluster de aplicación HA más comunes son actualmente de dos nodos, existen algunas soluciones de conmutación de varios nodos (más de dos nodos) para Linux que recientemente están disponible. Con los clusteres de configuración multinodo, tales como N+1 y en cascada de conmutación por error, estos ayudan a los administradores a cumplir con las necesidades de alta disponibilidad en un entorno complejo, mientras que 13

14 también proporciona una mejor utilización de los recursos. Por ejemplo, en una configuración N+1, un único servidor dedicado se ejecuta en modo pasivo, mientras que el resto de los servidores de proceso responden activamente las solicitudes de sus aplicaciones. Si un servidor falla completamente, el nodo pasivo proporciona todos los recursos de un servidor no utilizado, en vez de saturar la aplicación en otro servidor ya responsable de varias aplicaciones. Las configuraciones de múltiples nodos pueden ser ejecutadas ya sea mediante la duplicación de contenido de forma local en cada servidor o a través de una estructura de almacenamiento conmutada por el uso de SAN (Storage Area Network), que es una red de almacenamiento integral. Proporcionan clusters multinodo con excelentes servidores adicionales de almacenamiento que se aaden a la SAN, así como la capacidad de escalar de manera efectiva la cantidad de almacenamiento a los nodos del cluster. 2.7 Software Cluster HA en Linux HeartBeat: Un software de cluster activo-pasivo (de código abierto), que se utiliza comúnmente en los sistemas Linux. Soporta E/S fencing utilizando el mecanismo STONITH. Fácil de instalar: No vinculado a determinada SO, kernel. Originalmente se configuraban con archivos de texto. Ahora también hay una interfaz gráfica de usuario. Soporta múltiples nodos. Funciona con cualquier tipo de dispositivo de bloques. Cluster Suite de RedHat: Soporta también clusters activo-activo y activo-pasivo Muy sencillo: No hace un seguimiento adecuado de los recursos. Tiene una interfaz gráfica de usuario sencilla para configurarlo. Soporta E/S fencing utilizando el mecanismo STONITH. Funciona con cualquier tipo de dispositivo de bloques 14

15 Oracle RAC El servidor de base de datos Oracle 10 (también conocido como RAC Real Apliccations Cluster) soporta configuraciones de activo-pasivo y activo-activo. Si ejecuta una base de datos Oracle, por lo general no utiliza la máquina para otras cosas, por lo que no necesita un software de clster HA adicional. 3 Objetivo Exponer lo investigado acerca de Cluster Linux de Alta Disponibilidad, su arquitectura, configuración, funcionamiento y tecnologías, junto con la respectiva demostración de instalación de Heartbeat que soporte el servidor APACHE. 15

16 4 Desarrollo Paso a Paso - HowTo 4.1 Alta Disponibilidad con Heartbeat Primeramente debemos saber que es Heartbeat. Es un paquete de software creado por LINUX-HA, por medio del cual se lleva a cabo un proceso de verificación de los nodos que están activos y los que no están activos, y lo realizan todos y cada uno de los nodos del cluster, lanzando dos seales al resto de compaero del cluster. Una se llama LooksAlive, y suele ser un simple ping, y otra más autoritativa que se llama IsAlive, que se realiza en intervalos de tiempo (por defecto 60s). Este es un esquema de cómo se comportaría: El Cliente se conecta a una IP virtual que comparten ambos nodos, y dependiendo como lo tengamos configurado, uno recibiría la petición, en caso de que se detecte que no funciona correctamente el otro nodo esclavo obtiene el control del servicio en segundos. La forma de conectar a los servidores entre sí puede ser: un cable cruzado, un switch dedicado o una VLAN en un switch. 16

17 A continuación se explicará cómo configurar Heartbeat para dos nodos, y ofrecer un servicio de alta disponibilidad con un servidor principal y un mirror. La configuración de Heartbeat es idéntica en los dos equipos del cluster, por lo que haremos la configuración para nodo1 y la copiaremos a nodo2. Nodo 1: Hostname nodo1 principal: IP Address: Nodo 2: Hostname nodo2 espejo: IP Address: IP Virtual Linux-HA: El primer paso es instalar Heartbeat en ambas máquinas: apt-get install heartbeat Ponemos las IPs y hostnames en /etc/hosts de los 2 nodos: localhost nodo nodo2 Debemos modificar 3 ficheros en cada una de las maquinas, estos se encuentran en /etc/ha.d: authkeys ha.cf haresources En authkeys especificaremos las claves, para nuestro caso usaremos el método inseguro CRC (La comprobación de redundancia cíclica es un código de detección de errores usado frecuentemente en redes digitales y en dispositivos de almacenamiento para detectar cambios accidentales en los datos. Tiene menos carga de CPU) asumiendo que tenemos un buen 17

18 firewall configurado, podemos usar md5, o sha1 para mayor seguridad: auth 1 1 crc Y hacemos que sólo el usuario root pueda leer este archivo: chmod 600 /etc/ha.d/authkeys En el fichero ha.cf especificaremos las opciones de configuración de heartbeat, indicamos donde queremos guardar los logs, en keepalive le indicamos que los latidos se enviarán cada 2 segundos, en deadtime especificamos que si un nodo no responde en 30 segundos está muerto, en warntime le decimos que si no responde en 10 segundos nos lanzará una alerta, en el inicio antes de considerar un nodo muerto esperaremos 120 segundos para evitar problemas con el arranque del servicio, usaremos el puerto UDP 649 para la comunicación entre las máquinas, en ucast indicaremos nuestro dispositivo ethernet e indicamos que mandamos latidos por unicast a la ip del otro nodo (peer), ponemos el parámetro failback en on para indicar el comportamiento en caso de recuperación de un nodo caído, estando en on este recuperará todos los servicios al volver a estar activo si lo dejamos en off, los servicios residirán en el nodo espejo hasta que este caiga, indicamos que nodos forman el servicio, el nombre que indicamos debe coincidir con el que devuelve el comando uname -n en cada uno de los nodos y finalmente un dispositivo ethernet para broadcast. Definimos los logs logfile /var/log/ha-log logfacility local0 Tiempo en segundos entre cada latido keepalive 2 Tiempo en segundos en el que se considera un sistema inactivo deadtime 30 warntime 10 Tiempo de espera en segundos para interfaces que levantan lentamente initdead

19 Ping por interface que comunica ambos nodos (interface latido) La IP debe ser la interface del otro nodo ucast eth0 (ip del otro servidor) Interface por la que hacemos la comunicacin y el puerto udpport 694 Definir el tipo de failback auto failback on Nodos que componen el cluster node nodo1 node nodo2 bcast eth0 En el fichero haresources, especificaremos los servicios que debe manejar heartbeat (en este caso apache), este fichero es el mismo en los dos nodos. En este caso tenemos el nodo1 como activo y el nodo2 como pasivo: nodo1 IPaddr2:: /24/eth0 apache2 Creamos un fichero index.html para tener una prueba gráfica de qué nodo nos da el servicio: echo nodo1 apache test server en /var/www/html/index.html echo nodo2 apache test server en /var/www/html/index.html Reiniciamos el servicio Heartbeat en las 2 máquinas: /etc/init.d/heartbeat restart Abrimos el navegador y ponemos la url (ip virtual): Nos saldrá el mensaje nodo1 apache test server Ahora paramos el heartbeat en el nodo1 y el mensaje lo veremos en el nodo2 19

20 /etc/init.d/heartbeat stop Nos saldrá el mensaje nodo2 apache test server 20

21 5 Recomendaciones Al instalar Heartbeat, los 3 ficheros: authkeys ha.cf haresources No se encuentran por defecto en /etc/ha.d. En este mismo directorio debemos abrir el README y en su contenido no indicará donde los podemos encontrar; generalmente estan en /usr/share/doc/heartbeat. Debemos descomprimirlos ya que son ficheros con extensión.gz, una vez realizado solo queda copiarlos a /etc/ha.d. 21

22 6 Conclusiones Es de gran importancia para la organizaciones y empresas contar con los servicios que provee un cluster de alta disponibilidad, ya que mantiene en funcionamiento los servicios y operaciones, eliminando los problemas comunes de los sistemas de información de la organización, además, la información se encuentra consolidada y en el caso de una pérdida de datos o problemas de servicios, otra máquina tomará el rol de la principal, pudiendo tener un sistema continuo de datos sin afectar el negocio. Además, la alta disponibilidad nos permite poder tener los sistemas críticos funcionando un 99.9 porciento del tiempo, algo que generalmente es un desafío para los departamentos tecnológicos. Si ponemos en la balanza poder tener un sistema crítico en operación en un 99.9 porciento vs los costos de tener que quedar con los sistemas detenidos, podríamos tener clara la importancia de poder disponer de estas tecnologías que nos permiten un alto desempeo de la información. En el campo laboral, no olvidemos que el marketing es el eslabón entre la empresa y el mercado, y que junto con una buena selección de personal y una buena elección en tecnología es posible obtener éxito en las acciones que se planifique. Actualmente la alta disponibilidad es muy importante, con la necesidad de inmediatez, con la enorme cantidad de información bidireccional a gestionar y con la urgente respuesta que se requiere ante cualquier inconveniente, este requisito se ha convertido en una de las estrategias para ofrecer un servicio integral dentro de los planes tanto de comunicación como de mercadeo. 22