Cambios en la Topología de red

Primera fase

Esta imagen representa como se encuentra la topología de red en cuanto a la primera fase.

Segunda fase

En esta segunda imagen se observa que de acuerdo a las fases del proyecto, en esta se añade lo que es el servidor replica.

ReplicaciónHacemos la cita a la parte de Administración de bases de datos donde se explica detalladamente este apartado:

Replicacion en PostgreSQL.docxEn cuanto a la replicación, por parte de redes es necesario proporcionar en la red un servidor secundario prácticamente igual al primario, teniendo en cuenta que el tipo de replicación que usaran por parte de bases de datos será replicación sincrónica  multi-maestra.

Ahora, teniendo en cuenta que contamos con dos servidores, y necesitamos que haya una sincronización entre ellos en cuanto a los archivos, programas y aplicaciones que usaremos, utilizaremos UNISION que es una herramienta de sincronización de archivos, de código abierto que soporta de forma nativa la sincronización de archivos bidireccional.

Ya que usamos el protocolo NFS en nuestro sistema, esto nos permite tener un espacio accesible donde se encuentren todos los datos necesarios que necesitemos replicar.

A principio, las primeras sincronizaciones tenderán a ser “largas”, pero las siguientes por ser un proceso incremental, irán mucho más rápido.

Sencillamente, UNISION nos permitirá tener en ambos servidores el mismo conjunto de archivos tanto como directorios.

Protocolos

Consideramos pertinente anexar los siguientes protocolos a nuestro sistema:

DHCP

En cualquier red es necesario que todos los dispositivos que estén conectados a ella tengan una dirección asociada con la cual se establecen comunicaciones. El servidor DHCP facilita esta tarea porque asigna direcciones IP de manera automática.

DHCP (Dynamic Host Protocol) es un protocolo de red en donde un servidor asigna automáticamente direcciones IP a cada cliente teniendo absoluto control en esta tarea.

El Protocolo de Configuración Dinámica de Hosts (DHCP, en inglés), es un servicio de red que permite que los equipos hosts sean configurados automáticamente desde un servidor en lugar de tener que configurar manualmente cada host de la red. Los equipos configurados para ser clientes DHCP no tienen control sobre la configuración que reciben del servidor DHCP, y la configuración es transparente para el usuario del equipo.

Las opciones de configuración más comunes suministradas por un servidor DHCP a los clientes DHCP incluyen:

1. Dirección IP y máscara de red

2. Dirección IP o la pasarela predeterminada a usar

3. IP adresses of the DNS servers to use

Además, un servidor DHCP puede suministrar propiedades de configuración como:

1. Nombre del host

2. Nombre de dominio

3. Servidor horario

4. Servidor de impresión

La ventaja de usar DHCP es que un cambio en la red (por ejemplo, un cambio en la dirección del servidor DNS), solo supone un cambio en el servidor DHCP, ya que todos los hosts de la red se reconfigurarán automáticamente la próxima vez que sus clientes DHCP soliciten la configuración al servidor DHCP. Como una ventaja añadida, también es más fácil integrar nuevos equipos en la red, ya que no es necesario comprobar la disponibilidad de la dirección IP. Los conflictos de direcciones IP también se reducen.

Un servidor DHCP puede proporcionar parámetros de configuración usando los métodos:

“Manual allocation (MAC address)This method entails using DHCP to identify the unique hardware address of each network card connected to the network and then continually supplying a constant configuration each time the DHCP client makes a request to the DHCP server using that network device. This ensures that a particular address is assigned automatically to that network card, based on it's MAC address.

Dynamic allocation (address pool)In this method, the DHCP server will assign an IP address from a pool of addresses (sometimes also called a range or scope) for a period of time or lease, that is configured on the server or until the client informs the server that it doesn't need the address anymore. This way, the clients will be receiving their configuration properties dynamically and on a "first come, first

served" basis. When a DHCP client is no longer on the network for a specified period, the configuration is expired and released back to the address pool for use by other DHCP Clients. This way, an address can be leased or used for a period of time. After this period, the client has to renegociate the lease with the server to maintain use of the address.

Asignación automáticaUsing this method, the DHCP automatically assigns an IP address permanently to a device, selecting it from a pool of available addresses. Usually DHCP is used to assign a temporary address to a client, but a DHCP server can allow an infinite lease time.

The last two methods can be considered "automatic" because in each case the DHCP server assigns an address with no extra intervention needed. The only difference between them is in how long the IP address is leased, in other words whether a client's address varies over time. Ubuntu is shipped with both DHCP server and client. The server is dhcpd (dynamic host configuration protocol daemon). The client provided with Ubuntu isdhclient and should be installed on all computers required to be automatically configured. Both programs are easy to install and configure and will be automatically started at system boot.”

https://help.ubuntu.com/lts/serverguide/dhcp.html

NFS

Es un Sistema de Archivos distribuido que provee acceso transparente a discos remotos. Es independiente de la arquitectura, sistema operativo y protocolo de transporte de la red.Permite centralizar la administración de discos.

Posibilita que distintos sistemas conectados a una misma red accedan a ficheros remotos como si se tratara de locales.  El protocolo NFS está incluido por defecto en los Sistemas Operativos UNIX y la mayoría de distribuciones Linux.

Características Principales

Transparencia de acceso

El módulo Cliente de NFS ofrece una API idéntica a la interface del sistema operativo local. Los usuarios ven al sistema remoto como si fuese un Sistema de Archivos local.No requiere modificaciones a programas existentes para permitir que operen con archivos remotos.

Transparencia en la ubicación

Cada cliente agrega el Sistema de Archivos remoto en su espacio de nombres local.Los Sistemas de Archivos son exportados por el Server y montados (en forma remota) por los clientes.

Transparencia ante falla

El servicio NFS es stateless y las operaciones de acceso son todas de igual prioridad.Las operaciones de archivos de UNIX se traducen en calls de NFS por el módulo cliente.

¿Por qué utilizaremos NFS?

Aseguramos que los archivos de usuarios se encuentren disponibles desde máquinas locales, y evitar la copia de archivos a la máquina local. Con este protocolo el administrador de red tendrá un mejor control sobre ella. En cuanto a la seguridad, este protocolo no cifra los datos a ser distribuidos dentro de la red, pero teniendo en cuenta que nuestra red es local, y ésta delimitada a un determinado número de clientes, no representa un problema.

Arquitectura de Software“Una arquitectura de software para un Sistema, es la estructura o estructuras del mismo, que consiste en los elementos, y sus propiedades externamente visibles y la relación de interacción entre estos.”

Documenting software architectures, views and beyond

Tenemos contempladas dos tipos de arquitecturas de software para nuestro Sistema, debido a que por el momento se desconoce en gran mayoría como van a estar alojadas tanto las aplicaciones como el procesamiento de los datos.

Como primer caso tenemos una arquitectura cliente – servidor.

Esto es tomando en cuenta que la base de datos será proporcionada desde el “SIPE” entonces nuestros servidores no tienen una gran carga en cuanto al procesamiento y gestión de los datos.

Tendremos un servidor que solo ofrecerá los servicios, (alojamiento de los datos, en este caso solo nuestra base de datos)

Varios clientes que usarán los servicios proporcionados por nuestro servidor.

Obviamente la red que permitirá que los clientes accedan al servidor.

En este diseño de sistema, se refleja una estructura lógica de la aplicación como se ve en los siguientes puntos:

Capa de presentación: hace referencia a la aplicación alojada respectivamente en cada uno de los diferentes clientes.

Capa de Procesamiento: aquí es donde la aplicación instalada en cada cliente realiza el procesamiento correspondiente a esta internamente.

Capa de Gestión de Datos: en nuestro caso hace referencia a los servicios proporcionados por nuestro servidor, en este caso tomando en cuenta que el servidor solo proporciona los datos correspondientes para realizar los procesamientos debidos para las distintas necesidades de los diferentes clientes.

Como segundo caso tenemos una arquitectura cliente-servidor tres capas.

Tomando en cuenta que nosotros mismos realizaremos nuestra base de datos y será alojada dentro de nuestro servidor así como la aplicación.

Tendremos un servidor que solo ofrecerá los servicios, (alojamiento de los datos, en este caso solo nuestra base de datos)

Varios clientes que usarán los servicios proporcionados por nuestro servidor.

Obviamente la red que permitirá que los clientes accedan al servidor.

Nota: aquí debemos distinguir claramente esta separación ya que se distribuirá cada capa en el cliente y el servidor.

Se usara un tipo de cliente fino, por consecuente todo el “procesamiento pesado” (procesamiento de información y gestión de datos) ocurre en el servidor y en la red. Cabe mencionar que tanto la aplicación como la base de datos se alojaran en un mismo servidor.

Lo que nos proporcionara:

Centralización del control.

Los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda dañar el sistema. 

Escalabilidad.

Fácil mantenimiento.

Usando esta arquitectura se pueden presentar problemas de:

Congestión del tráfico.

No sucederá debido a que el número de clientes en nuestro sistema es muy reducido (4).

Rendimiento.

En nuestro sistema no será problema alguno, ya que realmente es un sistema relativamente sencillo, sabiendo que este tipo de problemas se presentan con más frecuenta en un sistema bancario por mencionar un ejemplo, donde sí se requeriría aplicar una arquitectura de capa 3 ya que el procesamiento y la gestión de los datos si es considerablemente mayor. Esto en cuanto al rendimiento.

El paradigma de C/S clásico no tiene la robustez de una red P2P.

Con los puntos anteriores, damos por consecuente que este problema está resuelto, pero no está por demás mencionarlo. Si en el caso extremo que nuestro servidor se llegará a caer, entra en funcionamiento el Servidor replica. Algo que no suponemos que pase, es que ambos colapsen, entonces si estamos jodidos.

Fuentes de consulta:

https://help.ubuntu.com/lts/serverguide/dhcp.html

http://www.fiuba6662.com.ar/6648/presentaciones/spollo/Superpollo.htm

http://es.wikipedia.org/wiki/Network_File_System