Servidores web: cloud
•Descargar como ODP, PDF•
0 recomendaciones•799 vistas
Presentación tema 4 de la asignatura "Servidores web" del Máster Universitario en Desarrollo de Aplicaciones y Servicios Web sobre cloud
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Servidores web: cloud
Similar a Servidores web: cloud (20)
Más de Juan Antonio Gil Martínez-Abarca
Último
Último (15)
Servidores web: cloud
- 1. AISI Administración de Servidores Web: AWS
- 2. MWS AWS AWS
- 3. MWS AWS Caso práctico: Start-up con app móvil que requiere computación y almacenamiento de datos l Opción A: Adquirir servidores y housing/hosting de la app en nuestra sede (in-house) l Opción B: En la sede de un 3º (con nuestros equipos o no, pero dedicados) l Opción B': hosting compartido l Opción C: Proveedor de Cloud introducción
- 4. MWS AWS Cloud computing: Pradigma que permite ofrecer servicios (cómputo, almacenamiento, etc) a través de Internet l Aprovechamiento de la economía de escala de los grandes proveedores l Pago por uso, sin inversión en infraestructura inicial: de hora de CPU, por GB almacenado + enviado/recibido l Aprovisionamiento dinámico l Permite que gasto en IT se convierta en gastos de operación en lugar de inversión Principal crítica: pérdida de control de datos introducción
- 5. MWS AWS Demanda de recursos es variable: [2,20]% con picos ante eventos extraordinarios introducción
- 6. MWS AWS cloud cloud Ajustar consumo a necesidades: Evita desperdiciar recursos de cómputo Evita pérdida de prestaciones soportando picos de carga
- 7. MWS AWS Cloud privado: infraestructura de uso exclusivo para una institución Cloud de comunidad: federación de recursos de diferentes organizaciones Cloud Público: todo el mundo mediante pago por uso Cloud híbrido: combinación privado con extensión a público Modelos de despliegue
- 8. MWS AWS Modelos de servicio Modelos: IaaS Para sysadmins
- 9. MWS AWS Platform as a Service (PaaS) l Proveedor proporciona al desarrollador API de plataforma para el desarrollo de apps que se ejecutan en la plataforma del proveedor l Desarrollador no gestiona ni HW ni SO subyacente l Ejemplos: Google App Engine, Heroku l Tanto AWS como Azure incluyen funcionalidad PaaS Modelos de servicio
- 10. MWS AWS cloud l Basado en virtualización l Permite disponer de un o más servidores completos (con GNU/Linux y Windows Server) con acceso root l Proporciona entorno propio: caso AWS (http://aws.amazon.com/es/) l Propio monitor: CloudWatch l Propia base de datos: RDS (Relational Database Service: MySQL, Oracle,…), simpleDB (noSQL), ElastiCache Propio balanceador: AutoScaler (https://aws.amazon.com/es/autoscaling/) , ELB (http://aws.amazon.com/es/elasticloadbalancing/) l Propio almacenamiento: Glacier (duraderos),S3 (http://aws.amazon.com/es/s3/), RRS (redundancia), EBS (http://aws.amazon.com/es/ebs/) l Amazon Route 53, Amazon Simple Email Service (SES) l Modelos: IaaS Para sysadmins
- 11. MWS AWS Es imprescindible diseñar una app escalable para poder aprovechar las ventajas de una infraestructura escalable Idealmente, una app desplegada en cloud constará de uno o más servicios que: l Permiten aprovisionar y liberar recursos (adaptación a cargas de trabajo variable) l Se comunican con otros servicios de forma desacoplada y gestionando contingencias l Están replicados l Distribuidos l Se despliegan y configuran automáticamente Apps Cloud
- 12. MWS AWS Aprovisionar y liberar recursos: l De cómputo: despliegue de instancias (EC2, Azure roles) l De almacenamiento de ficheros (S3, Windows Azure Storage) l De almacenamiento de información: Amazon RDS, SimpleDB y Windows Azure SQL DB Aprovisionamiento automático: l AutoScaling de AWS l Autoscaling Application Block de Windows Azure Comunicación desacoplada: Colas elásticas de mensajes: Amazon Simple Queue Service y Windows Azure Queue Storage Service Apps Cloud
- 13. MWS AWS Replicación: diferentes instancias l En cómputo: Podemos tener balanceador de carga (Amazon ELB, HAProxy) en conjunción con grupos de autoescalado (auto scaling) l En almacenamiento de información: Réplicas de lectura de base de datos con RDS (permite esquemas de replicación) l Ficheros: S3 y SimpleDB replican datos por tolerancia a fallos Distribución geográfica: AWS Regions y Windwos Azure regions l Aspectos: Latencia, usos de zonas disponibilidad para reducir latencia l Amazon CloudFront para distribuir contenido (estático, streaming) desde 14 localizaciones l Windows Azure Content Delivery Network (CDN) Apps Cloud
- 14. MWS AWS Una app cloud debe ser diseñada para aprovechar las capacidades cloud Idealmente debe cumplir los requisitos de alta disponibilidad, tolerancia a fallos, elasticidad, etc. AWS y Azure (y otros) ofrecen numerosos servicios que permiten la construcción de aplicaciones Cloud conclusiones
- 15. MWS AWS Servicios de infraestructura proporcionados por AWS: l Elastic Compute Cloud (EC2): “provides resizable compute capacity in the cloud” l Crea Vms instancias de servidor→ l Simple Storage Service (S3): “provides a web services interface that can be used to store and retrieve unlimited amounts of data, at any time, from anywhere on the Web” l Simple Queue Service (SQS): “distributed queue messaging service” conclusiones
- 16. MWS AWS Servicios de infraestructura proporcionados por AWS: l CloudFront: “content delivery network that delivers your content using a global network of edge locations” l SimpleDB: “a web service providing the core database functions of data indexing and querying” https://aws.amazon.com/es/simpledb/ l RDS: Base de datos relacional. 6 motores: MySQL, MariaDB, Oracle,... https://aws.amazon.com/es/rds/ Nota: Presupuesto de costes en AWS: https://calculator.s3.amazonaws.com/index.html conclusiones
- 19. MWS AWS Cloud Application Architectures,George Reese, O’Reilly, 2009 Cloud Security and Privacy,Tim Mather, Subra Kumaraswamy, and Shahed Latif, O’Reilly, 2009 Referencias
Notas del editor
- Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild. Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe. Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor. Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí). Prefork es la configuración predeterminada en la mayoría de instalaciones.
- Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild. Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe. Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor. Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí). Prefork es la configuración predeterminada en la mayoría de instalaciones.
- Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild. Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe. Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor. Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí). Prefork es la configuración predeterminada en la mayoría de instalaciones.
- Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild. Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe. Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor. Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí). Prefork es la configuración predeterminada en la mayoría de instalaciones.
- Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild. Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe. Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor. Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí). Prefork es la configuración predeterminada en la mayoría de instalaciones.
- Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild. Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe. Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor. Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí). Prefork es la configuración predeterminada en la mayoría de instalaciones.
- Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild. Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe. Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor. Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí). Prefork es la configuración predeterminada en la mayoría de instalaciones.
- Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild. Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe. Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor. Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí). Prefork es la configuración predeterminada en la mayoría de instalaciones.
- Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild. Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe. Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor. Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí). Prefork es la configuración predeterminada en la mayoría de instalaciones.
- Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild. Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe. Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor. Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí). Prefork es la configuración predeterminada en la mayoría de instalaciones.
- Wherever in your URL-space you do not have an Options FollowSymLinks, or you do have an Options SymLinksIfOwnerMatch, Apache will need to issue extra system calls to check up on symlinks. (One extra call per filename component.) For example, if you had: DocumentRoot "/www/htdocs" <Directory "/"> Options SymLinksIfOwnerMatch </Directory> and a request is made for the URI /index.html, then Apache will perform lstat(2) on /www, /www/htdocs, and /www/htdocs/index.html. The results of these lstats are never cached, so they will occur on every single request. If you really desire the symlinks security checking, you can do something like this: DocumentRoot "/www/htdocs" <Directory "/"> Options FollowSymLinks </Directory> <Directory "/www/htdocs"> Options -FollowSymLinks +SymLinksIfOwnerMatch </Directory>