Administracin de Sistemas Cliente/Servidor Distribuidos

Historia de los sistemas Distribuidos

En los aos 60, el problema de administracin de sistemas distribuidos no exista dado que estos se encontraban centralizados y usualmente almacenados dentro de un edificio, sin embargo, con el paso del tiempo, el poder, la complejidad y la conectividad entre los sistemas de cmputo y redes evoluciono. En la actualidad, las organizaciones y empresas dependen en gran medida de los sistemas de cmputo y redes de comunicacin para su operacin. Dado que esta infraestructura puede estar geogrfica y funcionalmente distribuida, la administracin de estos se convierte en una tarea critica. Al principio, la administracion de sistemas distribuidos no era problema, pues los sistemas estaban centralizados y usualmente almacenados en grandes edificios. En esos tiempos los sistemas no estaban interconectados y la informacion se compartia a travez de cintas magneticos, esto permitio que la administracion de estos sistemas se mantuviera centralizada, siendo realizada de manera periodica durante las horas en que los sistemas eran menos usados. Los sistemas distribuidos comenzaron a entrar en produccion a inicios de los 70 con la introduccion de la mini-computadora. Estos sistemas se encontraban usualmente aislados y eran usados para funciones especializadas o departamentales, usualmente les brindaban mantenimiento los fabricantes de los sistemas y proveian una sola funcion, tales como: inventarios, procesamiento de texto, puntos de venta, etc. La revolucion de la computadora personal llego en los 80's. Tan pronto las PCs comenzaron a aparecer, se fueron adquiriendo para uso individual o departamental. Las computadoras y sus datos se encontraban en el mismo lugar, aislados de los sistemas de procesamiento principal y de las redes. Eventualmente los usuarios de PCs y organizaciones tuvieron la necesidad de extraer informacion de bases de datos centralizadas y poderlas integrar con sus hojas de calculo y otras aplicaciones, esto evoluciono hasta tener aplicaciones de mision critica basadas en el intercambio de datos a travez de un mecanismo de comunicacion. La computadora personal se convirtio en parte de la estrategia general y de esta manera, la administracion de sistemas cambio para siempre. Los centros de datos ya no solo estaban preocupados por la administracion de sus sistemas centralizados, sino que tuvieron que encarar la problematica de administrar cientos de computadoras en otros centros de datos e inclusive un mayor numero de computadoras personales distribuidas en diferentes zonas geograficas. Es aqui cuando algunas empresas comenzaron a desarrollar aplicaciones para la administracion de estos sistemas distribuidos. En esos tiempos las principales areas de importancia eran: actualizacion de aplicaciones, administracion de configuraciones e inventario de aplicaciones y equipo.

Poco despues, otro fenomeno comenzo a ocurrir llamado "Red de Area Local" (LAN). Esta tecnologia permitia nuevos retos y posibilidaded; las aplicaciones y el equipo de computo podian ser compartidas y accesadas de una manera sencilla, las bases de datos podian ser instaladas en servidores de archivos compartidos. Estos cambios reducieron los problemas de distribucion de aplicaciones, equipos de computo y la administracion de configuraciones, pero trajo nuevos retos. Los equipos e informacion compartida requerian de un analisis de desempe~o para reducir los tiempos de respuesta y mejorar la productividad del trabajador. Nuevas aplicaciones aparecieron en el mercado denominadas cliente/servidor, que distribuian un poco del procesamiento centralizado que realizaban los servidores y supercomputadoras. Este nuevo paradigma fomento la creacion de nuevas areas de investigacion para la administracion de sistemas distribuidos: sincronizacion, monitoreo, rastreo de problemas entre otros. De manera similar, las redes se volvieron mas complejas al interconectar redes departamentales a travez de puentes, interruptores y enrutadores para crear redes de area amplia. El ambiente de los sistemas de computo, poco a poco se fue tornando en una tarea dificil de realizar, requiriendo grandes cantidades de recursos humanos de ingenieros para operar de manera efectiva los sistemas distribuidos. En los '90s, la explosion del WWW y la creacion de HTML evolucionaron los sistemas distribuidos. Lo que comenzo como un mecanismo para compartir documentos pronto se convirtio en un modelo de computo distribuido mundial. Las organizaciones comenzaron a usar el WWW para compartir informacion de productos de manera publica y privada, lo cual permitio la evolucion de los sistemas cliente/servidor a aplicaciones en navegador. La revolucion basada en el web creo nuevas posibilidades de integracion y de independencia de plataformas, las aplicaciones ahora podian ser desarrolladas sin importar demasiado la plataforma del cliente. Esto tambien introdujo la posibilidad de centralizar la administracion de servidores WWW y a disminuir la preocupacion en el desempe~o de la aplicacion en la plataforma del cliente. Un nuevo modelo de administracion de servicios distribuidos fue concebido. Clientes internos y externos ahora podrian conectarse a diferentes aplicaciones siendo albergadas en diferentes servidores, los cuales podrian estar fisicamente en diferentes sistemas de computo. Las herramientas de administracion de sistemas ahora podian ejecutar ciertas partes localizadas en diferentes sistemas de computo. Con la creacion de XML como mecanismo de codificacion de informacion, la idea de un sistema con infraestructura distribuida e independiente de plataforma tomaba forma. El uso de XML y HTTP permitia a cualquier sistema el poder enviar y recibir informacion estructurada para fines administrativos.

Qu es la Administracin de Sistemas Cliente/Servidor?

Concepto (1) La administracin de sistemas cliente/servidor distribuidos incluye las actividades como: manejo de la versin y distribucin del software, monitoreo de la utilizacin de los recursos y el mantenimiento del sistema de seguridad, entre otros.

Los administradores de sistemas cliente/servidor distribuidos se ocupan de monitorear continuamente al sistema y se deben de asegurar de su disponibilidad. Para una buena administracin, se debe de poder identificar las reas que estn teniendo problemas as como de la rpida recuperacin de fallas que se puedan presentar. La informacin que se obtiene mediante el monitoreo sirve a los administradores para anticipar situaciones crticas. La prevencin de estas situaciones ayuda a que los problemas no crezcan para que no afecten a los usuarios del sistema. Concepto (2)

ESTANDARES

Los estndares son aquellas normas usuales, los propsitos, los objetivos, a alcanzar, las metas a alcanzar y aquellos ndices que integran los planes, y todo dato o cifra que pueda emplearse como medida para cumplirlas, son considerados como estndares. Estas medidas son indispensables para el control, ya que indican la manera en que deseas que se ejecute una actividad. En la prctica, son los objetivos declarados y definidos de la organizacin y por esa razn los estndares deben abarcar las funciones bsicas y reas clave de los resultados logrados. Un estndar muy utilizado en los sistemas distribuidos es el CORBA, en el cual nos basaremos para explicar este tema. CORBA es el estndar para la creacin de sistemas distribuidos creado por el Object Management Group (OMG). Pensado para ser independiente del lenguaje, rpidamente aparecieron implementaciones en las que se poda usar casi cualquier lenguaje. Aunque objeto y componente tienen significado distintos, el nombre utilizado en las tecnologas de Microsoft COM y DCOM, versin distribuida de COM es componente. COM/DCOM es un sistema de componentes implementado en todos los sistemas operativos que fabrica Microsoft. La tecnologa para crear sistemas distribuidos proporcionada por Microsoft es una versin orientada a componentes del sistema RPC. Si bien es verdad que se han hecho algunos esfuerzos para que DCOM aparezca en arquitecturas diferentes a la Win32, por hoy, DCOM es una tecnologa que solo sirve para los sistemas Microsoft.

CORBA, Common Object Request Broker Architecture, es una tecnologa para crear sistemas distribuidos, creada por un consorcio de fabricantes, agrupados bajo el OMG. El estndar CORBA define qu ha de incluir una implementacin estndar, pero no cmo se han de hacer. Esta tarea se deja de la mano de los diferentes fabricantes. Esta es una de las principales caractersticas de CORBA: permite una total libertad a los implementadores siempre que estos respeten unos mnimos orientados a la interoperabilidad entre implementaciones. Ventajas 1) Disponibilidad y Versatilidad Muchas arquitecturas y sistemas operativos cuentan con una implementacin de CORBA, lo que hace suponer que se puede usar CORBA en virtualmente cualquier proyecto de sistemas distribuidos. 2) Eficiencia La libertad de desarrollo ha favorecido la existencia de estndar que se adaptan a multitud de posibles necesidades de los usuarios, generando una competencia que favorece aquellas implementaciones de mayor calidad y con ms caractersticas. 3) Adaptacin a Lenguajes de programacin Es posible emplear los servicios de CORBA desde cualquier lenguaje de programacin, desde C++, C Java, hasta COBOL Ada. Los ORBs (Object Request Brokers), es el ncleo de cualquier implementacin CORBA, transmiten los mensajes que se intercambian cliente y servidor, para lo que se ocupan de: 1. Canalizar las comunicaciones entre los objetos locales y los remotos. 2. Empaquetar los parmetros que el cliente pasa al mtodo remoto y el resultado que el mtodo devuelve al cliente. 3. Localizar al objeto remoto a partir de una referencia. IDL (Interface Definition Language) es un lenguajede programacin pensado exclusivamente para especificar las interfaces de las clases cuyas instancias queremos hacer pblicas a objetos remotos que las usaran como clientes. La necesidad de un IDL viene dada por la independencia de CORBA respecto a la arquitectura y al lenguaje de programacin. Distintos lenguajes soportan diferentes tipos de datos y tienen distintas formas de especificar clases. Incluso limitndonos a un lenguaje, la ordenacin y el tamao de un tipo de datos determinado no tiene porqu ser el mismo entre

arquitecturas diferentes (por ejemplo, no es lo mismo un entero en un 386 con MS-DOS que en un UltraSparc con Solaris 7). IDL pone de acuerdo a distintos lenguajes en el formato y tamao de sus especificaciones. El compilador de IDL transforma una especificacin neutral para la plataforma y el lenguaje en otra que puedan entender dicho lenguaje y plataforma Las implementaciones CORBA pueden ofrecer servicios adicionales voluntariamente. Un ejemplo de estas facilidades es el sistema de suscripcin de eventos, que permite que un objeto se suscriba a eventos generados por otro. El propsito de este servicio es el de mejorar la eficiencia disminuyendo el trfico de la red. Por ejemplo, si hay varios objetos clientes esperando a que suceda algo en el objeto que presta servicio en el servidor, en vez de hacer polling, podran solicitarle a este que les enve una notificacin cuando eso ocurra. El estndar CORBA no se preocupa de la seguridad implementada en el sistema distribuido. Si por alguna razn se requiere restringir el uso de los recursos controlados por un determinado objeto, debe hacerlo el usuario.

Dentro de los Sistemas Distribuidos (SOD) existen estndares los cuales ayudan a alcanzar metas u objetivos. Un estndar muy utilizado por los SOD es el CORBA ya que este estndar es utilizado para la creacin de sistemas distribuidos ya que permite una total libertad a los implementadores siempre que estos respeten unos mnimos orientados a la interoperabilidad entre implementaciones, asi como utilizar diferentes tipos de lenguajes de programacin. CORBA ha favorecido la existencia de estndar que se adaptan a multitud de posibles necesidades de los usuarios, generando una competencia que favorece aquellas implementaciones de mayor calidad de los SOD.

PROTOCOLOS DE ADMINISTRACION DE INTERNET

El Internet Group Management Protocol (IGMP) es un Internet protocolo que proporciona un camino para una computadora conectada a Internet a informar sobre sus multicast pertenencia a un grupo de al lado del router s. La multidifusin permite que una computadora en la Internet para enviar Ms informacin

Temas Archivo

el contenido de varios otros equipos que han identificado a s mismos como interesados en recibir el contenido de la computadora emisora. La multidifusin se puede utilizar para aplicaciones como la actualizacin de las libretas de direcciones de usuarios de computadoras porttiles en el campo, el envo de boletines de la empresa a una lista de distribucin, y la "emisin" de alto ancho de banda de los programas de streaming de medios de comunicacin a un pblico que ha "sintonizado" con la creacin de una pertenencia a un grupo multicast. Uso de la Interconexin de Sistemas Abiertos ( OSI ), modelo de comunicacin, IGMP es parte de la capa de red . IGMP se describe formalmente en la Internet Engineering Task Force ( IETF ) Request for Comments (RFC) 2236. GMP se utiliza entre el equipo cliente y un enrutador de multidifusin local. Interruptores con IGMP snooping obtener informacin til mediante la observacin de estas transacciones IGMP. Protocol Independent Multicast (PIM) se utiliza entre los routers de multidifusin local y remota, para dirigir el trfico multicast de la multidifusin servidor para muchos clientes de multidifusin. IGMP funciona por encima de la capa de red , aunque en realidad no actan como un protocolo de transporte . [1] [ no en la citacin dada ]

[ editar ] Normas
Hay tres versiones de IGMP, segn la definicin de " solicitud de comentarios "(RFC) los documentos de la Internet Engineering Task Force (IETF). IGMPv1 est definida por RFC 1112 , IGMPv2 est definida por RFC 2236 y IGMPv3 se defini inicialmente por el RFC 3376 pero desde entonces ha sido reemplazado por RFC 4604 que define tanto IGMPv3 y MLDv2. IGMPv2 mejora con IGMPv1, aadiendo la posibilidad de que una gran cantidad de seal de deseo de abandonar un grupo multicast. IGMPv3 mejora con el IGMPv2 principalmente mediante la adicin de la capacidad de escuchar a la multidifusin procedentes de un conjunto de direcciones IP de origen solamente. [2]

[ editar ] Host y implementaciones de router

El protocolo IGMP se ejecuta en un host en particular y dentro de un router. Una gran cantidad solicitudes de adhesin a un grupo a travs de su router local, mientras que un router escucha estas solicitudes y enva peridicamente consultas de suscripcin. El FreeBSD , [nota 1] Linux [nota 2] y de Windows de sistemas operativos de apoyo IGMP en el host. Para la ejecucin del lado del servidor, el caso de Linux utiliza un demonio como mrouted para actuar como un enrutador IGMP Linux. Tambin hay suites de enrutamiento completa (como XORP o Quagga ), que a su vez una computadora comn y corriente en un router multicast de pleno derecho.

[ editar ] Seguridad
IGMP es vulnerable a algunos ataques, [3] [4] [5] [6] y los cortafuegos habitualmente permiten al usuario desactivarlo si no es necesario.

[ editar ] IGMPv3 estructura de los paquetes

Mensajes IGMP se realizan en el desnudo paquetes IP con protocolo IP nmero 2. [7] No hay capa de transporte se utiliza con IGMP mensajes, similares a ICMP, por ejemplo.
[ editar ] Composicin de mensajes de consulta

Las consultas de miembros son enviados por los routers multicast para determinar qu direcciones de multidifusin son de inters para los sistemas conectados a su red. Los routers envan peridicamente consultas generales para actualizar el estado de pertenencia a grupos para todos los sistemas en su red. Grupo-Preguntas especficas se utilizan para determinar el estado de la recepcin de una direccin de multidifusin. Grupo-y-FuentePreguntas especficas permitir que el router para determinar si los sistemas de recepcin de deseo de los mensajes enviados a un grupo de multidifusin de una direccin de origen especificada en una lista de direcciones unicast.
IGMPv3 paquete de estructura poco desplazamiento 0 32 64 Resv S QRV 0-3 4 7.5 15.08 Max Resp Cdigo Grupo de Direccin QQIC Nmero de Fuentes (N) 16-31 Checksum

Type = 0x11

96 128

Origen de la direccin [1] Direccin de origen [2] ... Origen de la direccin [N]

Max Resp Cdigo Este campo especifica el tiempo mximo (en 1 / 10 segundos) permitido antes de enviar un informe en respuesta. Si el nmero est por debajo de 128, el valor se utiliza directamente. Si el valor es de 128 o ms, se interpreta como un exponente con mantisse. Checksum Este es el complemento a uno de 16 bits de la suma de los complementos a uno del mensaje IGMP todo. Grupo de Direccin Esta es la direccin de multidifusin que se consulta al enviar un grupo-o grupo-y-SourceSpecific Query. El campo se pone a cero cuando se enva una consulta general. Resv Este campo est reservado. Debe ser puesto a cero cuando se envan y se ignoran cuando se reciben. S (Suprimir router del lado de procesamiento) de la bandera Cuando se establece este indicador, que indica a los routers que estn recibiendo para suprimir las actualizaciones del temporizador normal. QRV (Variable Querier de robustez) Si esto no es cero, contiene el valor variable de robustez utilizado por el remitente de la consulta. Routers deben actualizar su variable de robustez para que coincida con la consulta ha recibido ms recientemente a menos que el valor es cero. QQIC (Cdigo intervalo de consulta de Querier) Este cdigo se usa para especificar el valor del intervalo de consulta (en segundos) utilizado por el entrevistador. Si el nmero est por debajo de 128, el valor se utiliza directamente. Si el valor es de 128 o ms, se interpreta como un exponente con mantisse. Nmero de Fuentes (N)

Este campo especifica el nmero de direcciones de origen presentes en la consulta. Para el general y consultas especficas de grupo, este valor es cero. Por-Grupo-y-Fuente Preguntas especficas, este valor es distinto de cero, pero limitado por la MTU de la red. Origen de la direccin [i] La Direccin de origen [i] los campos son un vector de direcciones IP unicast n, donde n es el valor en el nmero de fuentes (N) sobre el terreno.

[ editar ] IGMPv2 estructura de los paquetes

Definido por RFC 2236
IGMPv2 paquete de estructura + 0 32 Bits 0-7 Tipo 15.08 Max Tiempo Resp Grupo de Direccin 16-31 Checksum

Donde:

El tipo es pregunta de miembros (0x11), el Informe de Socios (IGMPv1: 0x12, IGMPv2: 0x16), Dejar grupo (0x17) IGMPv3 aade Informe tipo de membresa (0x22) Max Tiempo Resp especifica el lmite de tiempo para el informe correspondiente. El campo tiene una resolucin de 100 milisegundos, el valor se toma directamente. Este campo slo tiene sentido en la consulta de pertenencia (0x11), en otros mensajes que se establece en 0 e ignorado por el receptor.

Fuentes: http://translate.google.com.pe/translate?hl=es&langpair=en|es&u=http://www.networksorc ery.com/enp/protocol/igmp.htm http://translate.google.com.pe/translate?hl=es&langpair=en|es&u=http://www.inetdaemon.c om/tutorials/internet/igmp/index.shtml