Escalabilidad

La escalabilidad puede ser medida a lo largo de 3 dimensiones:

• Tamaño.
• Geográfica.
• Administrativa.

Escalabilidad de tamaño

Significa que podemos agregar más usuarios y recursos al sistema sin cualquier notable pérdida de rendimiento. Al momento de dar más soporte a usuarios y recursos, nos enfrentamos a menudo con las limitaciones de servicios centralizados, aunque muchas veces por muy diferentes razones. Con servicio centralizado nos referimos que son implementados en un único servidor o en cluster de servidores fuertemente acoplados en una misma ubicación. El problema de este esquema es que el servidor o el grupo puede volverse un cuello de botella cuando necesita procesar muchas solicitudes, principalmente por:

• La capacidad computacional, limitada por las CPUs.
• La capacidad de almacenamiento, incluyendo la taza de transferencia de E/S.
• La red entre el usuario y el servicio centralizado.

Escalar geográficamente

Los problemas para escalar de esta forma se dan porque por los sistemas distribuidos fueron diseñados para LANs, varias son basadas en comunicación síncrona. Y al pasar a WANs nos encontramos con:

• En WAN el tiempo de solicitud y respuesta es mucho más lento.
• En la WAN la red mucho menos confiable.
• En WAN la comunicación multipunto no encontramos muchas facilidades.

Escalabilidad administrativa

La pregunta aquí es: Cómo escalar un sistema distribuido a múltiples e independientes dominios administrativos? Los mayores problemas que necesitan ser resueltos son las políticas conflictivas con respecto al uso de los recursos (y pago), gestión y seguridad.

Una forma de compartir el equipamiento es conocida como computational grid. En estos grids, un sistema distribuido global es construido como una federación de sistemas distribuido local, permitiendo a un programa en una computadora en la organización A directamente acceder a los recursos de la organización B.

Si un sistema distribuido se expande a otro dominio,2 tipos de medidas de seguridad necesitan ser tomadas:

1. El sistema distribuido debe protegerse contra ataques maliciosos desde el nuevo dominio.
2. El nuevo dominio tiene que protegerse contra ataques maliciosos desde el sistema distribuido.

Como un contra ejemplo de sistemas distribuidos que abarcan múltiples dominios administrativos que aparentemente no presentan problemas de escalabilidad administrativa, se consideran las redes punto a punto para compartir archivos.

Técnicas para escalar

En la mayoría de casos. los problemas de escalabilidad en sistemas distribuidos aparecen como problemas de rendimiento causados por limitadas capacidades de los servidores y red. A menudo con mejorar sus capacidades (ej. incrementar memoria, actualizar CPUs. y reemplazar módulos de red) es una solución, pero nos referimos a escalar verticalmente. Cuando se trata de escalar horizontalmente, eso es, expandir el sistema distribuido en más máquinas, hay solamente 3 técnicas que podemos aplicar:

• Ocultar latencias de comunicación.
• Distribución de trabajo.
• Replicación.

Ocultando latencias de comunicación

• Aplicable en casos de escalabilidad geográfica.

La idea es simple: intentar evitar esperar por respuestas a solicitudes al servicio remoto tanto como sea posible. Eso nos lleva a la comunicación asíncrona. Hay casos de aplicaciones en donde, no se tiene nada más que hacer que esperar, que poder enviar la solicitud y atender otro asuntos mientras se espera la respuesta del servidor. En esos casos, es bueno analizar si hay tareas del servidor que son mejor realizarlas en el cliente, por ejemplo: verificar un formulario.

Particionamiento y distribución

Consiste en tomar un componente, dividirlo en partes más pequeñas, y difundir estas partes en el sistema. Un buen ejemplo de esto es DNS, que es jerárquicamente organizado dentro de un árbol de dominios, el cual está dividido en zonas no superpuestas. Básicamente, resolver un nombre significa regresar una dirección de red del host asociado. Considere el ejemplo el nombre flits.cs.vu.nl. Para resolver este nombre, primero es pasado al servidor de Z1 (Vea la figura más abajo) el cual retorna la dirección del servidor para la Z2, el cual el resto del nombre flits.cs.vu puede ser manejado, y así hasta llegar al host asociado.

Replicación

Considerando los problemas de escalabilidad a menudo aparecen en forma de degradación de rendimiento, es generalmente una buena idea la replicación de componentes a través de sistemas distribuidos. Esta no solo incrementa la disponibilidad, sino también ayuda a balancear la carga entre componentes llevando a mejorar el rendimiento. También en sistemas ampliamente dispersos geográficamente, tener un copia cercana puede ocultar mucho los problemas de latencia de comunicación mencionados antes.
El almacenamiento en caché es una forma especial de replicación, aunque la distinción entre los 2 es a veces dura de hacer. Consiste en hacer una copia de un recurso, generalmente en la proximidad del cliente accediendo al recurso. Sin embargo, en contraste de la replicación, esta es decisión del cliente de un recurso y no del propietario.
Sin embargo en ambos hay un serio inconveniente que afecta la escalabilidad. Porque ahora tenemos múltiples copias de un recurso, mantener la consistencia entre todas es el problema. Depende del uso del recurso esto puede ser tolerable.
Para terminar la replicación a menudo necesita de algún mecanismo de sincronización global. Desafortunadamente, tales mecanismos son extremadamente duros o incluso imposibles para implementar en una forma escalable, por las latencias que tiene la red naturalmente.