Guido Rubin Escalabilidad.

Slides:



Advertisements
Presentaciones similares
integrantes Avalos Aguilar María Cristina
Advertisements

PLANIFICACIÓN DE TESTING
ADMINISTRAR EL DESEMPEÑO Y LA CAPACIDAD
Control Interno Informático. Concepto
Tema2. Instalación y administración de DHCP. DHCP Failover Protocol.
III - Gestión de memoria
BASES DE DATOS DISTRIBUIDAS
Base de Datos Distribuidas FUNDAMENTOS DE BASES DE DATOS DISTRIBUIDAS
CREACION DE ESPACIOS VIRTUALES PARA TRABAJO EN EQUIPO
Aplicaciones Cliente-Servidor
Tecnologías Cliente / Servidor Capitulo III Richard Jiménez V. clienteserver.wordpress.com.
Virtual PC.
CONTROL DE CALIDAD.
Business Intelligence (BI) Software (Software de Inteligencia Impresario)
Base de Datos Distribuidas
Windows XP sp3.
Claudia Luz del Carmen García Ríos
Evaluación de nuevas Tecnologías
TEMA: Arquitectura Escalable Ing. Enrique Meneses Falla
Johanna Lizeth Rodríguez Lorena Fda. Chávarro Ramos
DATA WAREHOUSE Equipo 9.
Material de apoyo Unidad 4 Estructura de datos
Desarrollo de aplicaciones para ambientes distribuidos
Ciclo de Vida del Software
INTRODUCCIÓN. Motivación “Procesamiento distribuido significa dividir una aplicación en tareas y poner cada tarea en la plataforma donde pueda ser manejada.
TEMA 10. SISTEMAS OPERATIVOS DISTRIBUIDOS
INTEGRANTES: JOHN CARRIEL GOMEZ EVELYN CASTRO FLORES ELIANA MORA SUAREZ.
Estructuras en Sistemas Operativos DAISY KATERINE RODRÍGUEZ.
Introducción a los Sistemas Operativos
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
“condición que necesita el usuario para resolver un problema o conseguir un objetivo determinado”. Los requisitos de un sistema son los aspectos que el.
Términos y Conceptos Básicos
Ing. Noretsys Rodríguez. Definición de Conceptos  Falla: Ocurre cuando un programa no se comporta de manera adecuada. Es una propiedad estadística de.
Modelo de 3 capas.
VIRTUALIZACIÓN.
Unidad 2 – Gestión de Procesos
Ciclo de vida de un sistema
MARIANA PRECIADO VILLA TELECOMUNICACIONES 11º3
Gabriel Montañés León.  El sistema de nombres de dominio (DNS, Domain Name System) se diseñó originalmente como un protocolo. Antes de considerar qué.
ARQUICTECTURA DE SERVIDORES
LIA. SUEI CHONG SOL, MCE..  1.- SOFTWARE BÁSICO O DE SISTEMA. Conjunto de programas imprescindibles para el funcionamiento del sistema.  2.- SOTWARE.
ARQUITECTURA ALTERNATIVA DE SERVIDORES SISTEMAS OPERTIVOS DE RED En un sistema operativo de red los usuarios saben que están conectados a la red y que.
Tipos de Servidores.
Son los atributos de un sistema que son visibles para un programador, es decir aquellos atributos que impactan directamente en la ejecución lógica de un.
S ERVICIOS DE RED E I NTERNET T EMA 2: DHCP Nombre: Adrián de la Torre López.
Tecnologías Cliente / Servidor Capitulo II Richard Jiménez V. clienteserver.wordpress.com.
UD 2: “Instalación y administración de servicios de configuración automática de red” DHCP Failover Protocol Luis Alfonso Sánchez Brazales.
Unidad TemáticaI. Conceptos Básicos Horas Prácticas10 Horas Teóricas8 Horas Totales18 Objetivo El alumno determinará las entradas, procesos y salidas.
DHCP Failover Protocol
Aspectos para Diseñar un Sistema Distribuido:
DISCOS RAID (Redundant Array of Independent Disks)
SISTEMAS DE INFORMACION ORGANIZACIONAL
Tendencia De Los Sistemas Operativos
SOFTWARE DE INVERSION vs SOFTWARE PERSONALIZADO Conveniencias entre comprar o desarrollar un software a medida.
Elementos Conceptuales de proyectos: ¿Qué es un proyecto
Proceso de desarrollo de Software
TIPOS DE SISTEMAS OPERATIVOS.  Que es un sistema operativo??  Es el encargado de brindar al usuario una forma amigable y sencilla de operar, interpretar,
Luis Villalta Márquez.  DHCP Failover Protocol es un protocolo diseñado para permitir que una copia de seguridad del servidor DHCP pueda hacerse cargo.
Metodología para el Diseño de Sitios WEB
Son antivirus especialmente diseñados ara ofrecer protección desde la nube, salvaguardando al usuario contra nuevo códigos maliciosos prácticamente en.
Son antivirus especialmente diseñados para ofrecer protección desde la nube, salvaguardando al usuario contra nuevos códigos maliciosos prácticamente.
CONVENIENCIAS ENTRE COMPRAR O DESARROLLAR UN SOFTWARE A MEDIDA.
Contar con las licencias que avalen el uso del software. Imposibilidad de copia y modificación. Contar con los manuales y la asesoría directamente.
Conociendo el modelo Cliente-Servidor
Sistemas Distribuidos Conceptos Básicos Propiedades MSI. Nancy A. Olivares Ruiz.
BASES DE DATOS DISTRIBUIDAS M.C.C. María Guadalupe Villanueva Carrasco INGENIERIA EN SISTEMAS COMPUTACIONALES.
Conociendo el modelo Cliente-Servidor. Introducción En el mundo de TCP/IP las comunicaciones entre computadoras se rigen básicamente por lo que se llama.
Verificación y Validación del Software
{ Topología de Red Yaritza Ortega Astrid Zúñiga Vishal Patel.
Transcripción de la presentación:

Guido Rubin Escalabilidad

Introduccion Escalabilidad, como una propiedad de los sistemas, es generalmente difícil de definir. En cualquier caso particular, es necesario definir los requisitos específicos para la escalabilidad de las dimensiones que se consideran importantes. Un sistema que mejora el rendimiento después de añadir hardware, en proporción a la capacidad añadida, se dice que es un sistema escalable

Introduccion(2) La escalabilidad se define como la facilidad con que una solución puede adaptarse a las necesidades a medida que surjan. Cuando la infraestructura del servidor de una empresa es altamente escalable, significa que se encuentra en condiciones de adaptarse al crecimiento de la empresa en forma paralela, es decir, a medida que la empresa crece, crece su infraestructura. Con una sólida infraestructura y la planificación de escalabilidad, puede asegurarse de que su empresa puede manejar el crecimiento en el futuro.

Variables a tener en cuenta Escalabilidad – Numero de usuarios / Sesiones / Transacciones / operaciones que el sistema entero puede realizar Performance T. de respuesta. Disponibilidad Impacto por no disponibilidad Costos Mantenimiento

Factores a tener en cuenta Plataforma Hardware Diseño de aplicacion Estructura y arquitectura de base de datos Mecanismos de monitoreo.

Escalabilidad – SW La escalabilidad es la capacidad de mejorar recursos para ofrecer una mejora (idealmente) lineal en la capacidad de servicio. La característica clave de una aplicación es que la carga adicional sólo requiere recursos adicionales en lugar de una modificación extensiva de la aplicación en sí. Aunque el rendimiento marca una diferencia a la hora de determinar el número de usuarios que puede admitir una aplicación, la escalabilidad y el rendimiento son dos entidades diferentes. De hecho, las labores de rendimiento pueden ser opuestas a veces a las de escalabilidad.

Escalabilidad – SW (2) La escalabilidad debe formar parte del proceso de diseño porque no es una característica separada que se pueda agregar después. Debe haber una relación equilibrada entre software y hardware.

Escalar en Vertical El escalado vertical incluye agregar más memoria, más procesadores o procesadores más rápidos o, simplemente, migrar la aplicación a un único equipo más potente. Normalmente, este método permite un aumento en la capacidad sin requerir cambios en el código fuente. Desde el punto de vista administrativo, las cosas permanecen igual puesto que sigue habiendo un único equipo que administrar.

Escalar en Vertical(2) Actualizar un componente de hardware en un equipo sólo mueve el limite de capacidad de procesamiento de un lado a otro. Por ejemplo, una máquina que está al 100 % de uso de la CPU podría mejorar su capacidad agregando otra CPU. Sin embargo, la limitación puede pasar de la CPU a la memoria del sistema. Agregar CPU no aporta rendimiento en un modelo lineal. En su lugar, el rendimiento va disminuyendo cada vez que se agrega un procesador adicional. Para equipos con configuraciones de varios procesadores simétricos (SMP), cada procesador adicional produce una sobrecarga del sistema. Por tanto, un equipo con cuatro procesadores no obtendrá una mejora del 400% en capacidad sobre una versión con un único procesador. Una vez que haya actualizado todos los componentes de hardware al máximo de su capacidad, llegará el momento en que alcance el límite real de la capacidad de procesamiento del equipo. Llegado ese punto, el siguiente paso es escalar en vertical para moverse a otro equipo. Escalar en vertical conlleva también otros posibles problemas. El uso de un único equipo en el que basar una aplicación crea un único punto de error, lo que disminuye enormemente la tolerancia de errores del sistema. Si bien algunos métodos, como varias fuentes de alimentación, pueden implementar redundancia en un sistema de un único equipo, pueden resultar costosas.

Escalar en Vertical(3) Appserver, DBServer CPU Appserver, DBServer CPU RAM CPU RAM Appserver, DBServer

Escalar en Vertical(4) Ventajas Desventajas Facil de implementar. Limite finito. No escala linealmente. Requiere stopear el servicio. Unico punto de error

Escalar en Horizontal Escalar en horizontal aprovecha el ahorro que supone utilizar el hardware de PC activo para distribuir la carga de procesamiento en más de un servidor. Se logra utilizando muchos equipos. La colección funciona esencialmente como un único equipo.

Escalar en Horizontal(2) AppServer Load Balancer DBServer AppServer DBServer

Escalar en Horizontal (3)

Equilibrio de carga El equilibrio de carga permite escalar un sitio en horizontal a través de un clúster de servidores, facilitando la adición de capacidad agregando más servidores duplicados. También proporciona redundancia, concediendo al sitio capacidad de recuperación de conmutación por error, de manera que permanece disponible para los usuarios incluso si uno o más servidores fallan El escalado en horizontal proporciona un método de escalabilidad que no se ve mermado por limitaciones de hardware. Cada servidor adicional proporciona una mejora casi lineal de la escalabilidad.

Escalar en horizontal (4) La clave para escalar horizontalmente una aplicación con éxito es la transparencia de ubicación. Si alguna parte del código de la aplicación depende de saber qué servidor está ejecutando el código, no se ha logrado la transparencia de ubicación y será difícil el escalado en horizontal. Esta situación se denomina afinidad de ubicación. La afinidad de ubicación requiere cambios de código para escalar una aplicación en horizontal de un servidor a varios, lo que, en pocas ocasiones, constituye una opción económica. Si diseña la aplicación con transparencia de ubicación en mente, resulta más fácil escalarla en horizontal.

Escalar en Horizontal Ventajas Desventajas Mejora la tolerancia de errores. Desventajas Difícil administración debido al mayor numero de equipos.

Diseñar para la escalabilidad Cuando se diseña para ofrecer escalabilidad, el principal objetivo es garantizar una administración eficaz de los recursos. El diseño para la escalabilidad no está limitado a ningún nivel o componente concreto de una aplicación. Los arquitectos de aplicaciones deben considerar la escalabilidad en todos los niveles, desde la interfaz de usuario hasta el almacén de datos.

5 Preceptos No esperar Un proceso no debe esperar mas de lo necesario Procesos sincronicos Vs asincronicos.

5 Preceptos (2) No pelear por los recursos Ordenar el uso de recursos de menor a mayor. Las transacciones que utilizan recursos escasos deben ser llevadas a cabo lo mas tarde posible. Utilizar los recursos tan tarde y liberarlos tan pronto como sea posible.

5 Preceptos (3) Disenar app conmutables Se dice que dos o mas operaciones son conmutables si se pueden aplicar en cualquier orden y obtener el mismo resultado. Normalmente, las operaciones que se pueden ejecutar sin transacciones son candidatas.

5 Preceptos (4) Disenar app intercambiables Intentar generalizar los recursos. Cuanto mas general sean los recursos mas escalable va a ser la aplicacion.

5 Preceptos (5) Particionar recursos y actividades Disminuyendo las relaciones entre recursos y actividades, minimiza el riesgo de crear cuellos de botella. Dos recursos que dependen el uno del otro viviran y moriran juntos.

Probar escalabilidad Por ultimo es necesario realizar pruebas rigurosas y regulares para detectar problemas de escalabilidad. El proposito de las pruebas es identificar cargas de trabajo mayores y mitigar los cuellos de botella que puedan impedir la escalabilidad.

FIN