Cosas de Distribuidos I.

[z.facultad/75.74/practicos.git] / practicas / tp3_informe / tp_mom.latex

\documentclass[twocolumn]{article}
\usepackage{graphicx}
\usepackage{times}
\usepackage{hyperref}
\usepackage[activeacute,spanish]{babel}
\usepackage{fancyheadings}
% \usepackage[left=0.in,top=1.0in,right=0.75in,bottom=1.0in,nohead,nofoot]{geometry}
\columnsep 0.2in
\parindent 0.2in
\textheight=9.8in
\textwidth=7in
\headsep 0.0in
\topmargin=-1.0in

% Margein : Es 1in - oddsidemargin
\oddsidemargin -0.25in

\setlength{\headrulewidth}{0.0pt}

\renewcommand{\section}[1] {
        \begin{center}\Large \bf #1\end{center}
}

\renewcommand{\subsection}[1] {
        \begin{center}\bf #1\end{center}
}

%% HEADER
\rhead{\Large \bf Trabajo Pr\'actico Sistemas Distribuidos I 1º C. 2006}

\begin{document}

\title{SISTEMA DE CONTROL DE STOCK DE PRODUCCION: ANALISIS DE
       REQUERIMIENTOS DE SISTEMAS DISTRIBUIDOS}

\author{Leandro Lucarella\footnote{Leandro Lucarella, Facultad de
Ingenier\'ia, Universidad de Buenos Aires, llucare@fi.uba.ar} y Ricardo
Markiewicz\footnote{Ricardo Markiewicz, Facultad de Ingenier\'ia,
Universidad de Buenos Aires, rmarkie@fi.uba.ar}}

\maketitle
\thispagestyle{fancy}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Resumen}

En el presente trabajo proponemos una soluci\'on alternativa para
un Sistema de Control de Stock de Producci\'on para una empresa
automotriz que cuenta con varias plantas en distintos puntos del
pa\'is (Catamarca, C\'ordoba y Chubut). Actualmente utiliza un sistema
centralizado con varios problemas de base. La soluci\'on que proponemos
se basa en un sistema distribuido, utilizando como soporte un un
Middleware asincr\'onico para implementar un Publisher - Subscriber con
actualizaci\'on de informaci\'on y soporte de grupos, para mejorar tanto
la eficiencia como la confiabilidad y escalabilidad del sistema actual.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introducci\'on}

La empresa cuenta actualmente con un sistema centralizado (ver
Figura \ref{esquema}) que acarrea varios problemas de base, como la
inoperatividad ante fallas de conectividad, la eficiencia (el servidor
central est\'a al l\'imite de su capacidad) y la falta de escalabilidad
(lo que ser\'a un problema a corto plazo si la empresa crece al ritmo
esperado). Es por esto que presentamos como soluci\'on alternativa
un Middleware orientado a mensajes\cite{MOM} para atacar todas estas
falencias principales del sistema centralizado.

La empresa cuenta con 2 entidades que realizan operaciones bien
diferenciadas sobre el el stock de producci\'on: F\'abricas (producen
stock) y Puntos de Venta (o PDV, que consumen stock). A su vez cada
entidad puede tener otras restricciones sobre las operaciones, como por
ejemplo poder producir s\'olo cierto tipo de producto. Es por esto que
proponemos un Middleware con soporte de grupos\cite{GROUP}. Adem\'as,
dada la naturaleza Productor - Consumidor del problema es que proponemos
adem\'as un modelo Publisher - Subscriber\cite{PUBLISHER} para la
soluci\'on.

\begin{figure}
\begin{center}
\includegraphics[width=3.0in]{esquema.eps}
\caption{Infrastructura actual del sistema}
\label{esquema}
\end{center}
\end{figure}

La conectividad a nivel nacional de la empresa est\'a dada a trav\'es de
una red p\'ublica X.25\cite{X25} que, como cualquier red p\'ublica de
gran escala\cite{WAN}, tiende a tener problemas de estabilidad en los
enlaces de forma considerablemente peri\'odica, por lo tanto el modelo
m\'as adecuado ser\'a el asincr\'onico\cite{ASYNC} y habr\'a que tener en
cuenta el particionamiento\cite{PART} de la red para minimizar el impacto
en el sistema de la falta de conectividad, logrando una degradaci\'on
gr\'acil\cite{DEGRAD}.

Adem\'as de la conectividad a nivel nacional a trav\'es de una red
p\'ublica poco confiable, la empresa cuenta con LANs\cite{LAN} en
cada provincia con un nivel de confiabilidad muy alto, por lo que,
relacionado al particionamiento, proponemos la divisi\'on en sitios,
con conglomerado de participantes en los sitios\cite{SITE}. De esta
manera los participantes de un mismo sitio (o sitios con los que conserve
conectividad) pueden seguir funcionando de forma aut\'onoma utilizando
informaci\'on del stock local.

Para la comunicaci\'on entre los distintos participantes (ya
sea en un mismo sitio o sitios externos) proponemos entonces un
multicast\cite{MCAST}, de manera de que sea lo m\'as eficiente
posible y circule la m\'inima cantidad posible de mensajes por la red
p\'ublica que adem\'as tiene un costo por tr\'afico utilizado. Esto nos
conduce al problema del direccionamiento y de la selecci\'on de un
esquema de nombres\cite{NAMING} de participantes apropiado, para lo cual
proponemos un sistema de resoluci\'on de nombres\cite{DNS} jer\'arquico
y distribuido, para conservar la autonom\'ia local de cada sitio. Por
estos mismos motivos proponemos que la autenticaci\'on y permisos de
participantes en grupos utilicen un sistema an\'alogo de resoluci\'on.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Grupos}

El sistema actual requiere de distintos perfiles de usuarios. Hay usuarios
que s\'olo pueden modificar cierto tipo de producto (y s\'olo agregar
stock), hay otros que s\'olo pueden quitar stock, por ejemplo. Este
esquema se ajusta bien a un esquema de grupos con un sistema de
autorizaci\'on. M\'as espec\'ificamente este problema se ajusta a un
modelo de grupos de diseminaci\'on\cite{GROUP.DISSE}.

Para que todos los participantes tengan una visi\'on global del sistema
{\em precisa} y {\em consistente} es preciso contar con un servicio de
membres\'ia que consista de grupos {\em visibles} (ya que los grupos
son parte del problema y no s\'olo de la soluci\'on), una {\em vista}
y un esquema de orden adecuado. Este problema se ajusta, adem\'as, a un
modelo de grupos {\em cerrado} (porque s\'olo pueden enviar mensajes
a un grupo los miembros de este, ya que deben estar autorizados para
pertenecer al grupo y modificar el stock)\cite{GROUP.VIEW}.

Para todo esto es necesario tener el soporte de un protocolo de multicast
para la comunicaci\'on de grupos.

\subsection{Autorizaci\'on}
Para cumplir con los objetivos planteados, la soluci\'on que proponemos
consiste en un esquema similar a la resoluci\'on de nombres\cite{DNS}
ya que al ser un esquema distribuido asegura que no haya un punto \'unico
de falla, localidad y eficiencia utilizando un {\em cache}.

\subsection{Orden}
En principio notamos que un orden de tipo {\em FIFO}\cite{ORDER.FIFO}
no es necesario (puesto que los Puntos de Venta y las F\'abricas
ser\'an siempre participantes distintos). Sin embargo s\'i es
necesario un orden de tipo causal\cite{ORDER.CAUSAL}, porque de
otra forma podr\'ian quedar participantes con una vista del stock
en negativo\cite{ORDER.FIFO.FAIL}. Tambi\'en es necesario un orden
total\cite{ORDER.TOTAL} porque independientemente de la causalidad puede
darse el caso anterior en otras circunstancias\cite{ORDER.CAUSAL.FAIL}.

\subsection{Multicast}
Para poder implementar la comunicaci\'on de grupos es necesario
tener un protocolo de {\em multicast} con las siguientes
caracter\'isticas\cite{MCAST}:
\begin{description}
  \item[Enrutamiento] Responsable de eligir la ruta del origen al
        destino.
  \item[Tolerancia a omisiones] Responsable de lidiar con mensajes
        perdidos o corruptos.
  \item[Control de flujo] Responsable de minimizar la p\'erdida de datos
        por la falta de espacio en buffers.
  \item[Ordenamiento] Responsable de asegurar que los mensajes lleguen
        en un orden dado por el criterio visto en la secci\'on previa.
  \item[Recuperaci\'on ante errores] Responsable de reforzar el criterio
        de ordenamiento y confiabilidad en relaci\'on al cambio de la
        vista.
\end{description}

Esto es necesario para mantener la consistencia del sistema incluso
ante fallas en la conectividad de la red p\'ublica. Si alguna de estas
caracter\'isticas no estuviera presente, ser\'ia imposible asegurar esto.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Sitios}

El servicio de multicast debe atravesar varios sitios. Un sitio\cite{SITE}
es una LAN dentro de la WAN de LANs\cite{WAN}. Es importante un buen
manejo de sitios para evitar que el multicast atraviese redes que no
es necesario atravesar y esto no es una buena idea si hay que atravesar
una red p\'ublica que es lenta y que suele tener un costo por tr\'afico.

Para esto es necesario un mecanismo de detecci\'on de fallas de
comunicaci\'on entre sitios y de membres\'ia, para saber qu\'e sitios
est\'an activos.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Particionamiento}

Al estar dividido el sistema en sitios, separados por la red p\'ublica, es
de esperarse que hayan problemas de conectividad entre los sitios. Esto
es conocido como una partici\'on y aunque un esquema de partici\'on
primaria\cite{PART} puede resultar una soluci\'on simple, para este caso
creemos que es conveniente buscar un esquema m\'as adecuado.

Lo que proponemos es que, de acuerdo a los sitios activos que vea cada
participante, se de un estado de stock {\em local} a esa partici\'on. De
esta forma se puede seguir operando en todas las particiones (no
s\'olo la primaria) aunque no se cuente con el estado del stock global
(consigui\'endose una degradaci\'on gr\'acil\cite{DEGRAD}).

Al recuperarse la conectividad se puede reestablecer el stock global
simplemente revisando la diferencia de los stocks locales antes de
particionarse y enviandose esa diferencia entre las distintas particiones.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Asincron\'ia}

Al atravesar una red p\'ublica propensa a particiones, no se pueden dar
garant\'ias de tiempo, s\'olo pueden darse garant\'ias de {\em liveness}
(como, por ejemplo, se puede asegurar que "el mensaje llegar\'a
eventualmente", pero no dar precisiones de cu\'ando), debi\'endose
utilizar un modelo asincr\'onico\cite{ASYNC}.

Una desventaja de este modelo es que es muy dif\'icil diferenciar fallas
de tiempos de respuesta muy largos, por lo que es necesario agregar un
mecanismo de detecci\'on de fallas.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Esquema de nombres}

Para poder identificar a los distintos participantes de forma
independiente de la arquitectura utilizada por el middleware, es necesario
usar un esquema de nombre y por lo tanto un sistema de resoluci\'on
de nombres\cite{DNS}.

Proponemos un esquema jer\'arquico como el utilizado por
internet\cite{RFC1034}. Éste, si bien acarrea la utilizaci\'on de nombre
impuros, es muy conveniente para el problema analizado, debido a que
permite un correcto funcionamiento ante particiones (si hay al menos
un servidor de nombres en cada partici\'on), aprovecha la local\'ia
a trav\'es del uso de cache, proveyendo adem\'as redundancia ante
fallas y es eficiente porque distribuye la carga de la resoluci\'on de
nombres evitando que sea tanto un punto \'unico de falla como un cuello
de botella.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Actividades}

Cualquier sistema distribuido est\'a compuesto por una combinaci\'on de 3
clases de actividades primitivas\cite{ACTIV}: coordinar\cite{ACTIV.COORD},
compartir\cite{ACTIV.SHARE} y replicar\cite{ACTIV.REPLI}.

Nuestra propuesta no es la excepci\'on, aunque se centra en s\'olo 2
actividades principales, de las cuales es responsable el m\'odulo de
administraci\'on de stock.

\subsection{Compartir}
El sistema tiene que compartir una visi\'on global de stock. Para
que el acceso a este recurso sea consistente es que se analizaron los
requerimientos de orden, que aseguran que siempre que se modifique dicho
stock, se haga de forma coherente.

\subsection{Replicar}
Debido a la posibilidad de particiones propusimos un esquema de
diseminaci\'on que permite que la informaci\'on de stock se replique en
todos los sitios, de manera tal que ante problemas de conectividad cada
sitio pueda seguir trabajando con su stock local. La consolidaci\'on ya
se ha explicado que es simple, s\'olo hay que calcular la diferencia de
stock que hubo en el tiempo sin conexi\'on.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Arquitectura general}

A continuaci\'on presentamos, de forma resumida, un esquema de la
arquitectura general del sistema propuesta en base al an\'alisis realizado
en las secciones anteriores.

\begin{figure}
\begin{center}
\includegraphics[width=3.0in]{arquitectura.eps}
\caption{Arquitectura general del sistema}
\label{arquitectura}
\end{center}
\end{figure}

Como se puede apreciar en la Figura \ref{arquitectura}, el sistema que
proponemos est\'a basado en una arquitectura conocida\cite{GROUPARCH}
que consiste en 2 capas principales: Participantes y Sitios. Cada capa
est\'a compuesta por una serie de m\'odulos que pasaremos a describir
brevemente a continuaci\'on.

\subsection{Detector de fallas de sitios}
Este m\'odulo es responsable de la detecci\'on de fallas en la
comunicaci\'on entre sitios, fundamental para proveer un servicio de
membres\'ia de sitios para el manejo de particiones en caso de falla en
el enlace de la red p\'ublica.

\subsection{Multicast de red}
El m\'odulo de multicast de red provee comunicaci\'on {\em multi-peer}
no confiable a nivel de capa de red (como podr\'ia ser el servicio
de multicast que provee IP) como mecanismo b\'asico para el pasaje
de mensajes entre los nodos del sistema.  Este m\'odulo utiliza el
Detector de fallas de sitios para propagar los mensajes s\'olo a los
sitios activos.

\subsection{Comunicaci\'on de grupos}
Este m\'odulo es el encargado de agregar confiabilidad y orden a la
comunicaci\'on multicast para cumplir con la sem\'antica y restricciones
a nivel de grupos, proveyendo una comunicaci\'on entre participantes
adecuada para garantizar los requerimientos del sistema.

\subsection{Membres\'ia de sitios}
Este m\'odulo es el encargado de proveer informaci\'on sobre la
membres\'ia de los sitios participantes (activos) de los grupos, de manera
que el servicio de multicast no disemine mensajes en sitios inactivos.

\subsection{Detector de fallas de participantes}
Es an\'alogo al detector de fallas de sitios pero a nivel de
participantes. Informa a otros m\'odulos cuando se suma o se retira
un participante.

\subsection{Autorizaci\'on de participantes}
Este m\'odulo usa un modelo similar a la resoluci\'on de nombres\cite{DNS}
para proveer informaci\'on sobre los grupos a los que puede asociarse un
participante. La estructura jer\'arquica distribuida permite aprovechar
la localidad en caso de particionamiento.

\subsection{Membres\'ia de participantes}
Provee informaci\'on de membres\'ia a nivel de participantes, la vista
\cite{VISTA}. Utiliza el detector de fallas de participantes y membres\'ia
de sitios para saber qu\'e participantes est\'an activos.

\subsection{Administraci\'on de stock}
Este m\'odulo es el que se encarga de, en base a la informaci\'on que
provee la membres\'ia de sitios y participantes, dar una vista de la
informaci\'on de stock del sistema, seg\'un la conectividad disponible
como as\'i administrar las actividades distribuidas\cite{ACTIV}.

\subsection{Participantes}
Son las entidades del sistema: F\'abricas y Puntos de Venta. Son los
verdaderos usuarios del middleware. Se comunican s\'olamente con el
m\'odulo de Administraci\'on de stock quien los abstrae del resto de
la arquitectura del sistema, proveyendo una interfaz simple para que
los programadores de la aplicaci\'on no deban lidiar con los problemas
complejos del sistema distribuido.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Conclusiones}

Dados los requerimientos del modelo de negocio, y el costo de la
utilizaci\'on de la red p\'ublica, el modelo planteado impone una
soluci\'on \'optima para garantizar el bajo costo en las comunicaciones,
como tambi\'en as\'i dar garant\'ias de consitencia en la informaci\'on
manejada por los sistemas clientes que utilizan el middleware.

Un esquema de trabajo como el planteado ayudar\'a a mejorar la
integraci\'on de los diferentes grupos dentro del sistema y garantizar
una correcta escalabilidad del sistema a largo plazo, pudiendo integrar
nuevos grupos o nuevos clientes a los grupos existentes en la actualidad.

Tambi\'en se consigue mejorar la tolerancia a fallas y la disponibilidad
del sistema, consiguiendo una degradaci\'on gr\'acil ante particiones
a diferencia de la soluci\'on actual que deja inoperable al sistema
por completo.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Referencias}
\bibliography{tp_mom}
\bibliographystyle{is-unsrt}

\end{document}

% vim: set tw=74 :