Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Construcción de Aplicaciones de Avanzada con Geo-Distribución

770 views

Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Construcción de Aplicaciones de Avanzada con Geo-Distribución

  1. 1. Building Geo-Distributed Web Applications Jason Rexilius Founder, CEO - hostedlabs UTPL May 28 2009
  2. 2. Quien es Jason? •Arquitecto, hacker, problemático, fundador de compañías •Sistemas de intercambio financiero, telecomunicación wireless, seguridad nacional •PHP, perl, C, SAS, cualquier cosa con filos peligrosos
  3. 3. Que significa Geo-Distributed? Una sola aplicación ejecutándose simultáneamente en muchas localidades en el mundo. ES: es un cluster de clusters, comportándose como la imagen de una sola computadora. (grid, cloud, etc.) NO ES: • Clustering alojado sobre dispositivos compartidos como NFS en un centro de datos. (ej. MediaTemple) • Sitio de respaldos con replicación de datos (ej. SunGard) • Creación instantánea de sistemas virtuales (ej. Amazon EC2)
  4. 4. Objetivos • Escalamiento - Escalar arbitrariamente. Entrar a Digg, Slashdot y CNN al mismo tiempo y todavía dar un buen servicio. • Rendimiento - reducir el tiempo de espera entre el usuario y la aplicación, esto incluye alcanzar mercados globales. • Disponibilidad - Cero tiempo de inactividad. Operación continua, sin importar los problemas ambientales. Puede con todo, desde perdida de nodos a perdida del backbone regional. • Intensidad - Permitir procesamiento intensivo en recursos sin impactar las operaciones. Computación distribuida, búsqueda, almacenamiento etc.
  5. 5. Por que quiero hacer esto otra vez? • Capturar el éxito - ame a Digg, deje al equipo de marketing ser libre, sirva a sus usuarios apenas le descubran. • Donde están sus usuarios? - son el WORLD WIDE web..
  6. 6. • Tiempo es Dinero - “33% de los consumidores comprando con una conexión de banda ancha no esperan mas de 4 segundos para que una pagina Web se muestre.” - JupiterResearch via Akamai Cada segundo mas lento es una baja en clicks en publicidad (ganancias) • Proveedores Descarrilados – “ISPs fallan en enrutamiento” (Level3 vs Cogent) – “FBI Shutters Web Host” (su vecino aloja warez) – “Akamai Outage Raises Questions” (falla jerarquica) – Incendio en estación de energía apaga Equinix – Falla de generador de 365Main (mal mantenimiento) – Apagon en Rackspace (borracho en un camion)
  7. 7. Prepararse para la inundación Optimización prematura es mala. Ignorar sus objetivos también es malo Que puede hacer hoy para posicionarse mejor mañana? 1. Piense mas allá de la base de datos 2. Permita la especialización 3. Mejore ese viejo SO 4. Disciplina estricta con las interfaces de datos 5. No reinvente la rueda
  8. 8. Donde quiere terminar • Alcance los mercados mayores - suficientes ubicaciones para servir al mundo, pero no demasiadas
  9. 9. Como se ve esto? • Arquitectura nTier típica de una vista física
  10. 10. Como funciona? Aduéñese del proceso completo - desde bloques IP a DNS a servir el contenido, procesamiento de aplicación y persistencia de datos. (ver http://stevesouders.com/hpws/rules.php) 1) Optimice BGP/DNS para encaminar el trafico las localidades, distribuir el trafico por los nodos y encaminarlo fuera de los problemas. 2) Usar nodos Sub-Dominios/CDN para mejorar el rendimiento, sacar el trafico de los servidores de aplicación y particiones de trabajo. 3) Sesiones auto describibles y compartidas, nivel de cache distribuido permite a los usuarios moverse. No crea en los proveedores, niveladores de carga no siempre funcionan. 4) Usar diferentes capas de persistencia para necesidades diferentes. Volátil corto-plazo vs. largo plazo, etc. Se necesita un ambiente global pero administración de datos simple. 5) Usar el modelo de implementación de BD mas simple que se pueda (maestro/esclavo, two-phase commit, particionamiento de datos, etc. NDB es difícil, casi imposible en WAN). 6) Modelo “control workstation” para coordinar, revisar y administrar todos los niveles.
  11. 11. Administración de Trafico Global BGP/anycast DNS Geo-weighting Load Distribution • Optimización de primer nivel de enrutamiento Anycast, DNS es el primer punto • Geo-weighting basado en quien lo requiere, siguiente nivel • 8 respuestas para todo, póngalo dentro de un paquete UDP •Tablas actualizadas en tiempo real de registros A (no use CNAMEs) • Migre bloques ip en tiempos de inactividad (/24 tamaño mínimo) • IP assumption dentro del centro de datos • Use un sistema wing-man para simplicidad • Use grandes pilas de direcciones IP antes que niveladores de contenido
  12. 12. Nivel de Contenido Web • Use un directorio separado para el contenido estático – /var/www/webapp (direcciona a www.you.com, contiene PHP) – /var/www/static (direcciona a static.you.com, contiene JPG, JS, etc.) • Establezca EnvVars en httpd.conf para varios ambientes –SetEnv STATICURL http://devstatic.you.com – SetEnv STATICURL http://qastatic.you.com – SetEnv STATICURL http://static.you.com • Llame a las EnvVars en sus plantillas HTML para contenido estático <html> <img src=“<?php print $_SERVER[‘STATICURL’]; ?>/you_logo.gif”> </html> • Use replicación simple de datos para transferir de SVN o el sistema de archivos a CDN – crontab -e – svn deploy script
  13. 13. Nivel de Aplicación Web • Sesiones auto describibles - combinación de cookie/servidores cache Pseudo code: if ( $Compressed_Encrypted_Session_Data < 4000 bytes ) { Store_Session_In_Cookie( $Compressed_Encrypted_Session_Data }else{ Store_Session_In_Two_Nodes( $Node1, $Node2, $Compressed_Encrypted_Session_Data ) Store_Location_Of_Session_In_Cookie ( $Node1, $Node2 ) } • Uso estricto de interfaces de datos Function SQLRead($accessstring,$type,$constraints); Function SQLWrite($dataobject,$type,$constraints); Function FileRead($file,$method,$constraints); • No use AUTOINCREMENT, genere llaves • Use fork/exec para procesos largos/pesados antes que hilos de ejecución, use wrappers, IPC definido
  14. 14. Caching • MemcacheD es su amigo (o los parecidos) • “pre compile” paginas que son semi-dinámicas como noticias, etc. Piense cronológicamente • Obtenga listas y otros datos semi-dinámicas de la BD, genere includes locales • APC u otros opcode compile caches help • Overlay cache manager con modelo pub/sub para actualizaciones en background • Use locator keys para apuntar al cache “system of records”
  15. 15. Persistencia • Guarde los datos correctos en el lugar correcto – filesystem – berkleyDB – MySQL – REST interface to – MogileFS • Sistemas de archivos Global Namespace (Coda, Andrew, Lustre, et al.) – Use procesos en background para forzar caching y replicacion – Use nombres de directorios para implicar niveles de servicio o patrones de comportamiento • Escoja una arquitectura de BD apropiada “patrón de diseño”, use interfaces – Primary master, multi-slave, default read from slave – Primary master, two-phase commit, multi-slave – Partitioned, distributed multi-master, slave failover – distributed “hash-map” master, overlay query model
  16. 16. Principios • HTTP NO TIENE ESTADOS, use esta ventaja •Conozca y optimice toda la pila del sistema, no solo el lenguaje de programación • 3i’s - Interfaces, Indirección e Independencia como características de diseño de sistemas • Service Oriented Architecture != Webservices solamente, utilice múltiples modelos y métodos
  17. 17. Gracias MorphoDev Morpho, LLC New York | Chicago | Quito www.morphodev.com Morpho Development provides web application outsourcing services to small and medium sized companies in the United States. Morpho skillsets include: •PHP5/MySQL –PEAR libraries, smarty, Zend and CakePHP framework –Content Management Systems like Drupal and WordPress •HTML/CSS coding and Javascript development –Web standards and semantic markup, Ajax techniques and popular frameworks like prototype.js and Jquery We're growing, and we're looking for developers. So if you are interested, please contact us. Info@morphodev.com

×