La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Cloud Computing con Microsoft Windows Azure

Presentaciones similares


Presentación del tema: "Cloud Computing con Microsoft Windows Azure"— Transcripción de la presentación:

1 Cloud Computing con Microsoft Windows Azure
Alberto Díaz Arquitecto de soluciones General de Software de Canarias José Fortes Jefe de Proyectos Grupo Número 1

2 ¿Qué es Cloud Computing?
Definición sencilla: Es un paradigma de computación en el que los usuarios acceden a servicios que se ejecutan en Internet (la nube). Servicios de computación como suministro básico (commodity): agua, luz, teléfono, internet, servicios de computación ¿Qué es Cloud Computing? En los últimos años y meses el término Cloud Computing cada vez suscita más curiosidad, la gente quiere saber cada vez más lo que es, prueba de ello es la gráfica de búsquedas que muestra el aumento de “presión buscadora” sobre Cloud Computing que nos arroja Google Insight. El Cloud Computing pretende convertir la capacidad de procesamiento informático en un commodity, en un servicio básico de fácil acceso y que se tarifica por consumo básicamente. Normalmente será por cuota de suscripción + consumo realizado.

3 ¿Qué es Cloud Computing?
Hace 100 años quien tenía electricidad era gracias a su propio generador eléctrico General Electric transforma la electricidad un commodity Ventajas: reducción del precio, pago por suscripción + consumo Hace más de 100 años las casas que tenían luz tenían su propio generador eléctrico --> General Electric se da cuenta de que puede beneficiarse de un modelo de economía de escala y hace evolucionar esta situación a un estado en el que la luz es un servicio básico, un commodity al que se accede pagando una suscripción y el coste de lo consumido. Podríamos hacer un paralelismo con ese escenario y el de capacidad de computación proporcionada por CPDs propios en cada empresa o por Cloud Computing en el escenario actual.

4 Características del Cloud Computing
Alta disponibilidad garantizada por el Service Licence Agreement de Azure y Amazon (Google no tiene SLA): 99,95% uptime para la computación 99,90% detección de errores en aplicaciones  se resetean 99,90% uptime para el almacenamiento Tolerancia a fallos: Alta redundancia  3 replicas en cada momento Alta escalabilidad  procesamiento infinito Elasticidad  upscale y downscale al vuelo (tiempo ínfimo para aprovisionar una nueva VM) Pago por uso (pay as you go) Self-service  No se necesita hacer peticiones a TI Alta disponibilidad: Es dificil que en un CPD propio privado alcancemos niveles de uptime superiores a estos  99,95% de uptime significa que sólo hay 4,38 horas al año que no está disponible. Muy difícil mejorar esto, a nadie se le ha caído el exchange más de 2 horas en un mismo día?  En un día ya te has comido la mitad del margen anual de fallo que tienes. Tolerancia a fallos: actualmente se están haciendo tres réplicas de cada máquina virtual. Estas réplicas se distribuyen tanto dentro del propio container como fuera del container pero dentro del espacio geográfico elegido. Alta escalabilidad: da la ilusión de procesamiento infinito, hablamos de cientos de máquinas virtuales y de cientos de teras de almacenamiento. Elasticidad: se puede escalar y desescalar al vuelo, lo que hace que el sistema sea completamente elástico y lo estiremos o contraigamos como un chicle. Pago por uso: sólo pagamos por la cantidad de procesamiento que consumimos (más un precio por suscripción). Esto transforma CAPEX en OPEX, dejando flujo de caja libre para dedicar a otras inversiones. Self-Service: no hay que contar con gente de sistemas para aprovisionar más potencia o configurarla  Windows Azure Developer Portal, los desarrolladores sólos se bastan.

5 Ventajas del Cloud Computing
Mejor aprovechamiento de la capacidad de procesamiento: actualmente servidores “dormidos”  sólo 15% de procesamiento utilizado en CPDs en el mundo Se evita una fuerte inversión inicial para un CPD propio  libera flujo de caja para invertir en otras áreas Se ajusta el coste al uso real del procesamiento  se paga por lo que se necesita y no se derrocha (CAPEX  OPEX) Oportunidad para empresas pequeñas y medianas: poder competir con las grandes Optimización de recursos para las empresas grandes  No CPDs sobredimensionados ni que se quedan cortos Facilita la inversión y la desinversión!  Importante para la gestión de una empresa Todas las empresas: quedan liberadas de la gestión de TI  pueden centrarse en su negocio y no en instalar un Service Pack o monitorizar una VM Ventajas Derroche de procesamiento actual --> se calcula que sólo el 15% de procesamiento existente en el mundo en todos los CPDs se utiliza (muchos servidores dormidos mucho tiempo y luego tienen picos) Evitar fuerte inversión inicial  Libera flujo de caja para poder invertir en I+D u otros gastos! Ajusta el costo al uso real de las aplicaciones --> Se paga por lo que se necesita y no se desperdicia Se transforma el CAPEX (Capital Expenditure) en OPEX (Operational Expenditure)  Inversiones de capital para compra de activos necesarios en gasto por coste operacional Facilita la inversión y desinversión: para una empresa es muy importante tanto levantar con facilidad una unidad de negocio como cerrarla y desinvertir. Si a la empresa le va bien con esa unidad de negocio se le echa más combustible, se contrata más capacidad de procesamiento, pero si va mal no se come la inversión sino que puede desinvertir y volver a liberar ese capital.

6 Ventajas del Cloud Computing
Primera imagen: La gráfica escalonada representa las capacidades de TI que adquirimos a lo largo del tiempo conforme a las inversiones que vamos haciendo. Como se puede ver, el valor de la gráfica en el eje Y en un instante dado de tiempo representa nuestro tope estático de capacidad TI y, por tanto, nuestro tope para innovar. No podemos desarrollar nada que se salga de esta capacidad, que por otro lado es estática y no puede crecer cuando nosotros lo necesitamos porque así lo necesita un desarrollo. La gráfica curva representa el workload real, la carga de trabajo real de nuestras aplicaciones sobre la infraestreuctura de TI. Como vemos, nuestras aplicaciones generan una carga que no es constante en el tiempo, sino que varía notablemente. Puede corresponder a una aplicación o aplicaciones con picos. Segunda imagen: En la primera parte de la gráfica vemos que tenemos capacidad de TI desperdiciada, o hablando en las tres dimensiones reales y no geométricas (espacio, tiempo y dinero)  estamos desperdiciando dinero. Por otro lado, hay un momento de pico en el que no tenemos suficiente capacidad de TI para satisfacer la demanda, nuestras aplicaciones no están entregando el rendimiento adecuado y tenemos a clientes descontentos. Tercera imagen: El Cloud computing nos permite hacer un traje a medida para las capacidades de TI que necesitamos. Se ajusta mucho mejor a nuestras necesidades cambiantes en el tiempo. Como punto de partida reducimos las inversiones iniciales para adquirir capacidad de TI. Luego conseguimos no desperdiciar capacidad sino disponer de lo justo (siempre algo por encima) para lo que necesitamos. No damos mal servicio a los clientes, no hay deficiencia de capacidad de TI. Finalmente, podemos reducir el gasto si la carga de trabajo también se reduce. Por tanto, estamos ajustando tanto el coste como las capacidades a la carga de trabajo real demandada por nuestras aplicaciones.

7 ¿Qué aplicaciones son candidatas para Cloud Computing?
Se benefician claramente del Cloud Computing: Aplicaciones que requieran escalabilidad “Internet” Aplicaciones estacionales  loterías, rebajas en Grupo Número 1 Aplicaciones con picos  El Bintazo de Binter, matrícula de la ULL Aplicaciones con crecimiento exponencial de contenido generado por los usuarios  flickr, facebook, web de compraventa Pueden no ser idóneas: Aplicaciones con uso muy lineal, sin perspectivas de crecer Se requiere absoluto control sobre el entorno Se requiere la soberanía absoluta de los datos  datos financieros sensibles de la empresa Aplicaciones que son candidatas: Aplicaciones que requieran escalabilidad Internet  Pasaré de pocos a muchos usuarios y necesito que escale sin problemas. Aplicaciones estacionales  Habrá épocas en las que la aplicación será accedida muchísimo y otras en las que bastante menos. Esto es muy duro de resolver con un CPD propio, o se desperdicia mucha potencia o hay carencia cuando viene la demanda fuerte. Aplicaciones con contenido generado por los usuarios  Este contenido no es muy sensible, no son datos financieros de nuestra empresa y puede crecer exponencialmente en el tiempo. Aplicaciones que no son idóneas: Aplicaciones con uso muy lineal: siempre tiene 200 usuarios, que son los usuarios internos  tal vez no necesite de la nube Se requiere absoluto control sobre la infraestructura y el entorno  Si vas a GSC y entras en el departamento de tarjetas sólo les hace falta hacerte un análisis de sangre al entrar y al salir, es un entorno muy delicado y certificado, con lo que todo lo que se ejecute ahí, por medidas de conformidad con la certificaciión que se les exige no puede estar en la nube, son datos muy sensibles.

8 Tipos de Nube Nube pública: Nube privada:
Servicios accesibles desde internet Windows Azure, Google App Engine, Amazon Web Services Nube privada: Tener un CPD no es tener una nube privada  debe cumplir los principios de aprovisionamiento y elasticidad de la nube DELL, Telefónica, cliente (miles de servidores) VMware vCloud Windows Azure Appliace  anunciado en WPC 2010 La nube pública es la nube de la que prácticamente siempre vamos a estar hablando, es la que es omnipresente y se lleva el 90% del protagonismo merecidamente, ya que es la opción a elegir por el 90% de las empresas, dadas sus características, sus capacidades de inversión y sus infraestructuras existentes. La nube privada está pensada para proveedores de servicios, como DELL o Telefónica, e incluso para clientes finales, pero todos con CPDs inmensos  Miles de servidores, no nada de lo que podamos tener por aquí en nuestras empresas. Es decir, son empresas, tanto las de servicios como los clientes finales, que su infraestructura de TI es tan abismal que pueden llegar a conseguir el producir capacidad de TI bajo demanda como un commodity. Esto no está al alcance de empresas con CPDs modestos. Con Windows Azure + Windows Azure Appliace se pretende cubrir todo el espectro que va desde el proveedor global de nube, como Microsoft, a los proveedores de servicio intermedio, como Telefónica o DELL e incluso a los clientes finales con sus propios CPDs.

9 Muchas siglas: IaaS, PaaS y SaaS
IaaS: Infraestructure as a Service Sólo proporciona máquinas virtuales, pero al estilo C.C.  de manera elástica y self-service Ideal para migrar aplicaciones legacy a la nube PaaS: Platform as a Service Completa plataforma que permite la ejecución de software desarrollado a medida Formado por: entorno de ejecución, herramientas de desarrollo, servicios horizontales (control de acceso, monitorización) Permite entregar software desarrollado a medida como servicio  Interesante para empresas de software, clientes que desarrollen a medida, etc. SaaS: Software as a Service Es el más conocido, productos acabados para el usuario final, pero entregados como servicio Hotmail, Gmail, Facebook, Twitter, Tuenti, etc. Existe un gran baile de términos y conceptos que conviene aclarar: IaaS, PaaS y SaaS. IaaS: proporciona infraestructura como servicio, es decir, sólo da máquinas virtuales, eso sí, al estilo cloud computing, de manera elástica y self service, lo que lo diferencia de un hosting tradicional. Su punto fuerte es la migración de aplicaciones legacy a la nube, ya que en la infraestructura entregada por el IaaS se puede montar el mismo escenario de ejecución que en los servidores del CPD propio y hacer la transición del mismo a la nube sin problemas. Paas: proporciona una completa plataforma para la ejecución de software desarrollado a medida, entorno de desarrollo para fabricar ese software y servicios horizontales como monitorización, control de acceso, etc. Es interesante para ISVs, clientes que desarrollen software a medida y, en general, para cualquier que quiera entregar software desarrollado a medida como servicio. SaaS: Es la forma más conocida de Cloud Computing, permite entregar software de usuario final, productos acabados como servicio: hotmail, gmail, facebook, Sharepoint Online, etc. SaaS puede ayudar a empresas pequeñas y medianas a disponer de la misma potencia de aplicaciones y servicios antes sólo accesibles a aquellas que pudieran hacer una gran inversión  Sharepoint Online, Exchange Online. Sin SaaS o pagas CPD y licencias o no puedes disfrutar de estas herramientas. SaaS también mejora el time to market de un producto, ya que una vez desarrollado es accesible por todo el mundo instantáneamente, sin requerir venta de licencias ni implantaciones.

10 Muchas siglas: IaaS, PaaS y SaaS
IaaS PaaS SaaS vmWare vCloud: IaaS privada  te da máquinas virtuales al estilo Cloud Computing pero sólo en tu propio CPD. En esas máquinas virtuales puedes ejecutar lo que quieras, obviamente. El stack de SO + frameworks, etc. lo montas tú. Amazon Elastic Compute Cloud (EC2): IaaS pública  te da máquinas virtuales al estilo Cloud Computing alojadas en Internet donde puedes ejecutar lo que quieras, no tiene plataforma propia. Amazon Web services: Proporciona almacenamiento y una API de servicios para trabajar con ese almacenamiento, pero no proporciona una plataforma completa de ejecución propia. Cuál es el lenguaje y plataforma de desarrollo de Amazon Web services? No hay. Consumes servicios de la API SOAP o REST para relacionarte con su almacenamiento y servicios a través de .NET, J2EE o Python, pero no desarrollas algo y lo despliegas en la plataforma, porque no es tal. Google App Engine: PaaS programable en Java y Python, pero lo que se desarrolle para esa plataforma no podrá ejecutarse en tus servidores privados, ya que no tienes la plataforma Google App Engine debajo para ejecutarla. Por otro lado, no es apto para soluciones empresariales ahora mismo, ya que no dispone de SLA, como vimos antes. Windows Azure: completa plataforma de desarrollo, disponible de manera pública y privada  Azure appliace anunciado la semana pasada en el WPC 2010. Proporciona una completa plataforma de ejecución, programable en lenguajes horizontales de la plataforma .NET, lo que da la gran facilidad de poder migrar esas aplicaciones y sacarlas a tu CPD cuando quieras. No es una nube con tecnología vertical que sólo sirve para construir aplicaciones para esa nube y si las sacas de ahí no las puedes ejecutar en ningún sitio, como es el caso de force.com, que utiliza su lenguaje de programación propio. Proporciona una experiencia de desarrollo completa y prácticamente idéntica a lo ya conocido de .NET para los desarrolladores y para ejecutar lo desarrollado. Aparte de esto, también es una plataforma abierta, puedes programarla en Java, Python, PHP o lo que quieras y utilizar herramientas como Eclipse o Ruby. Windows Azure multiplataforma  Python, PHP, Ruby, Java, Eclipse  Cualquier cosa que se pueda subir a la VM y configurar por script funcionará. Puedes subir binarios JAVA y Azure levantará la JRE para ejecutarla, te provisiona de la software stack por debajo. Hay SDKs para hacer todo eso más fácil aún, e incluso tienes un Role directamente para esto: FAST CGI Role.

11 Microsoft y el Cloud Computing
Antecedentes de Microsoft en la nube: 11 años operando enormes CPDs para servicios de Internet Servicio a más de 500 millones de usuarios de Live Mail y Messenger Hosting para más de 620 mil buzones de Exchange sólo en España CPDs y tecnología que soportan: 240 mil millones de mensajes de messenger al mes 30 mil millones de autenticaciones por Live ID al mes 10 mil millones de páginas vistas en MSN al mes 2 mil millones de búsquedas con Bing al mes

12 CPDs de Microsoft Nuevos Generation 4 Data Centers:
Entre 10 y 100 CPDs  paranoia entre Google, Microsoft y Amazon Miles de metros cuadrados en varios continentes albergando estos CPDs (Europa, EEUU y Asia) Se trabaja nivel de container, no de servidores ~2000 servidores por contenedor Si un servidor se rompe no se cambia  cuando hay muchos rotos se cambia el container entero Capacidad de escalar instantánea  se trae un nuevo container y se enchufa Se están añadiendo 10 mil servidores al mes Inversión de $ por CPD Eficiencia energética = 1,2 W estándar = 2 W

13 CPDs de Microsoft para Azure
Independientemente de los CPDs para los servicios Cloud de la propia Microsoft, se han creado y se siguen añadiendo nuevos CPDs exclusivos para alojar soluciones en Azure de clientes de Microsoft. Es decir, para lo que conocemos como la nube pública Windows Azure en sí. La semana pasada en el WPC se habló mucho de Windows Azure (y de Windows Phone 7 curiosamente también), quedando muy claro que Azure y el Cloud Computing son algo totalmente estratégico para Microsoft ahora y en los próximos años. Este es un container al estilo de los que llevan los CPDs de Windows Azure. La densidad de los servidores es unas 10 veces mayor que en un CPD normal.

14 Windows Azure

15 Windows Azure Microsoft® Windows® Azure™ provides on-demand, cloud-based computing, where the cloud is a set of interconnected computing resources located in one or more data centers. Similar a un OS para la nube: abstrae del hardware a través de virtualización y libera de la gestión de la infraestructura Ofrece computación y almacenamiento bajo demanda alojada en los CPDs de Microsoft (y ahora en CPDs propios  Azure Appliance) Es multilenguaje: Todos los lenguajes de la plataforma .NET  de manera nativa e integrada con Visual Studio Java, Python, PHP, Ruby  a través de FastCGI con IIS Básicamente cualquier cosa configurable a través de un script se ejecutará en Windows Azure Proporciona una experiencia de desarrollo muy similar a la tradicional  Visual Studio, Eclipse Es accesible mediante protocolos estándar: SOAP, REST La definición en inglés es una definición de la propia Microsoft. Aquí se puede ver el claro ejemplo de que se puede distinguir cuando un abogado ha formado parte del equipo de producto, tiene marcas registradas por todos lados. Windows Azure es realmente como un SO para la nube: nos abstrae del hardware, la configuración de la red, la gestión de los balanceadores de carga, la monitorización para saber si las aplicaciones están en los parámetros de salud correctos, etc. Todo esto lo gestiona Azure y nosotros vemos simplemente una plataforma sobre la que desplegar desarrollos, nada más, todo funciona sólo y automatizadamente. En este sentido, Windows Azure automatiza y nos abstrae de muchas gestiones de fontanería, de la misma manera que un SO para un PC hace con la gestión de los dispositivos de entrada salida, los drivers, el acceso al almacenamiento, la gestión de la red, etc. Distinguir bien que hay dos grandes servicios para los que se puede usar la nube: ejecución de software (capacidad de procesamiento) y almacenamiento. Es decir, podemos querer utilizar la nube para ejecutar una aplicación en ella, que puede acceder a datos o no (lo normal será que lo haga), pero lo que sí es más frecuente es querer utilizar la nube sólo como servicio de almacenamiento. Podemos utilizar este servicio sin hacer uso del servicio de procesamiento, están separados y se permite sin problemas.

16 ¿Quién usa Windows Azure?
Anunciado en WPC 2010 de junio: DELL Provee la infraestructura para 20 de las 25 mayores webs del mundo y para 4 de los mayores buscadores Fujitsu Mayor proveedor de hardware de Japón y tercero a nivel mundial 5000 empleados especializados en la nube Ebay 75 mil millones de transacciones SQL diarias 60 mil millones de $ en transacciones económicas anuales 90 Millones de usuarios activos HP En la WPC de la semana pasada Microsoft se ha sacado un as de la manga y ha dado un puñetazo en la mesa haciéndose la foto con unos partners de un calibre espectacular, que despejan cualquier duda sobre el nivel de adopción y aceptación de la plataforma, al igual que, sin duda, van a generar un fuerte efecto de arrastre. Los partners salieron al escenario con Bob Muglia, uno de los presidentes de Microsoft a hablar de lo mucho que les gustaba Windows Azure y de cómo lo habían implantado o lo iban a implantar próximamente. Fue algo bastante serio y se quiso que se tuviera buena constancia de ello con la escenificación que se hizo.

17 Windows Azure Windows Azure: SO para la nube  proporciona entorno de ejecución y abstrae de la infraestructra SQL Azure: RDBMS para la nube -- es básicamente SQL Server AppFabric: Control de acceso y Enterprise Service Bus Gestión plataforma: Windows Azure Portal y API Herramientas de desarrollo: Azure SDK y Development Tools La plataforma de Windows Azure consta de 3 componentes principales: Windows Azure: Microsoft vende Windows Azure como su OS para la nube, porque provee de todas las características necesarias para alojar y ejecutar servicios en la nube. Proporciona un entorno de ejecución, incluyendo servidor web, almacenamiento no relacional (a través de tablas, blobs y colas), servicios de gestión y monitorización y balanceadores de carga. Por todo esto, Azure es una suerte de OS que abstrae al desarrollador de aplicaciones de toda la infraestructura subyacente. Windows Azure también proporciona a los desarrolladores el Development Fabric, donde se pueden desplegar aplicaciones y ejecutarlas sin necesidad de hacer despliegues en la nube real. SQL Azure: Es el sistema de almacenamiento relacional (RDBMS) de Microsoft para la nube. Provee de prácticamente todo lo que un SQL Server normal en un servidor local. Se puede acceder a él de las mismas maneras que un SQL Server normal: ADO.NET, ODBC, LINQ, EF, etc. Se pueden utilizar las mismas herramientas que usamos con un SQL Server local: Management Studio, Visual Studio, Reporting Services, etc. AppFabric: Provee de control de acceso (íncluso identidad federada) y del EnterPrise Service Bus de Windows Azure que, entre otras cosas, permite conectar aplicaciones on-premise con cloud.

18 Windows Azure Compute: servicio de procesamiento
Windows 2008 Server R2 64 Bits Hyper-V IIS 7.5 Storage: almacenamiento no relacional y mensajería asíncrona. API accesible via REST Tables Blobs Queues  similar a MSMQ Drives  Blobs formateados como VHDs NTFS Management: gestión automatizada de la infraestructura y la salud de los servicios alojados en Windows Azure Gestión automatizada de VMs y despliegue de roles en ellas Gestión automatizada de switches, routers y balanceadores de carga Fabric Controller  Mantiene los parámetros de salud elegidos para el servicio Windows Azure, como OS para la nube está compuesto por: Compute: Es el servicio que ofrece la potencia de cómputo escalable, está basado en servidores de 64 bits con Windows 2008 Server R2 e Hyper-V. Éstá diseñado para escalar dinámicamente y bajo demanda, también provee de IIS 7.5 para servir aplicaciones web. Podemos configurar el tamaño de instancia al crear un servicio para Azure. Podemos elegir desde máquinas con 1 core, 1,7 GB de RAM y 250 GB de HD hasta con 8 cores, 14 GB de RAM y 2 TB de HD Storage: proporciona tres tipos de almacenamiento: Tables: almacenamiento estructurado no relacional, modelo de almacenamiento conocido como Entity Model. Pensado para proveer de almacenamiento super escalable de datos particionados. ¿Por qué un almacenamiento no relacional? Todos los datos no necesitan de un RBDMS, hay ciertos tipos de datos que pueden ser almacenados de forma muy eficiente en un almacenamiento como el de Storage, por ejemplo el tipo de datos que se generan en un sitio de comercio electrónico puede almacenarse de manera eficiente en este tipo de almacenamiento Blobs: Diseñado para el almacenamiento de datos multimedia como fotos, videos o música. Ideal para un sitio de streaming de contenidos. Cada blob como máximo puede almacenar 50 GB. Queues: proporcionan mensajería asíncrona para comunicar los roles de Windows Azure, similarmente a como MSMQ conecta procesos asíncronamente en un entorno Windows local. Management: Gestión automatizada del servicio, encargado de la gestión de red, aprovisionamiento y despliegue de máquinas virtuales, etc. Se verá más adelante cómo hace todo esto a través del Fabric Controller.

19 Windows Azure Arquitectura de un servicio (aplicación) Windows Azure:
Una aplicación Windows Azure está formada por uno o varios web roles (que son directamente aplicaciones web: ASP.NET, ASP.NET MVC o Web Services, WCF), Worker Roles (DLLs .NET que se usan para procesar trabajo en background normalmente) y la definición y configuración del servicio completo. En la definición y configuración se establece declarativamente de qué es lo que se va a aprovisionar en Windows Azure, es decir, cuántas máquinas virtuales, de qué tamaño (small, medium, large, extra large), cuántas VMs par Web Roles y cuántas para Worker Roles, qué EndPoints se exponen (acceso HTTP, HTTPS, en qué puertos, etc.). Todo esto se empaqueta en un formato específico para Windows Azure y se despliega, bien en el propio Windows Azure o bien en el Development Fabric para ejecutarlo en local en la fase de desarrollo. Explicar cómo podríamos tener 10 web roles para un frontal en internet de una web y 1 sólo web role para que sea el portal de administración de la web. Necesitaríamos escalar con esos 10 web roles, pero con el de administración no vamos a tener problema porque siempre se espera un número bajo y lineal de usuarios. De hecho podríamos tener perfectamente esa web on-premise. Twitter: es el frontal el que necesita escalar, no la parte de administración, es con el frontal con el que podemos beneficiarnos muy bien del cloud computing.

20 Windows Azure Funcionamiento de Windows Azure
Una vez desplegado en Windows Azure un servicio, ¿cómo funciona? El Fabric Controller se encarga del despliegue, monitorización y mantenimiento de los parámetros de salud del servicio. Cuando se despliegue un servicio en Windows Azure, el FC aprovisiona los recursos hardware necesario, levanta el número de máquinas virtuales requeridas por el servicio y especificadas en la definición y configuración del servicio, instala el stack necesario para que se ejecute cada rol en las máquinas virtuales (una app web llevará IIS y un worker role no, una app Java llevará JRE, etc.) y despliega las VMs en el hardware aprovisionado. A partir de aquí el Fabric Controller está constantemente monitorizando la salud del servicio y si cae un nodo, inmediatamente aprovisiona otro y vuelve a desplegar el servicio. Información adicional sobre el Fabric Controller: Fabric Controller The fabric controller (FC) manages the life cycle of Azure services. It allocates resources for them, provisions, deploys them, monitors them, and maintains their goal state. It also manages and monitors both VMs and physical machines in the fabric. State machine The FC has an internal state machine that it uses for managing the life cycle of a service. It maintains the current (last known) state of each virtual and physical node, which it updates by on talking with FC agents on each machine. It also knows the goal state of each service that's been published. The state machine maintains internal data structures for logical services, logical roles, logical role instances, logical nodes, and physical nodes. The FC's main loop is described as a heartbeat. During each heartbeat, it compares its services' goal states with the current state of the nodes they're deployed on, if any. When it finds a role with a goal state that doesn't match its nodes' current state, it tries to move the node's state toward the role's goal state. If it can't, it might move the role instance to another node. The FC also monitors for certain events that move nodes out of goal state, e.g. failures.

21 Windows Azure Compute Explicar cómo funciona una aplicación en azure basándose en el patrón típico mostrado en la imagen

22 Windows Azure Storage Windows Azure Storage proporciona almacenamiento escalable de dos tipos: estructurado y no estructurado. Es altamente escalable, ya que hablamos de poder almacenar cientos de terabytes de datos. El servicio de almacenamiento de datos es independiente del servicio de procesamiento de Windows Azure, aunque se usa normalmente en conjunción con él. Esto significa que no se utiliza la misma máquina virtual para un web role y su almacenamiento, es completamente independiente, con su propia redundancia por triplicado, etc. Actualmente se replican los datos por triplicado, tanto dentro del propio CPD como en otros CPDs de la misma región. Constantemente se está escaneado los datos para descubrir fallos, si se encuentran se regeneran y se vuelven a replicar. El servicio de almacenamiento es accesible via una API REST, con lo cual se puede acceder desde cualquier cliente que sea capaz de implementar llamas REST sobre HTTP.

23 Windows Azure Storage Blobs
Blobs: proporciona almacenamiento para binarios grandes, especialmente enfocado a contenido multimedia: imágenes, video y audio. Está organizado en cuentas, contenedores y blobs. Cada cuenta puede tener el número de contenedores que se quiera y cada contenedor puede tener el número que se quiera de blobs.

24 Windows Azure Storage Blobs Accesibles a través de una URL:
http(s)://<storage account name>.blob.core.windows.net/<container>/<blob name> Permiten operaciones CRUD Se pueden usar CDNs para acercar el contenido a los usuarios Block Blobs: 200 GB en bloques de 4 MB Óptimos para streaming Page Blobs: Tamaño máximo predefinido de 1 TB en páginas de 512 KBs Óptimos para accesos aleatorios a los datos CDNs: Si los usuarios que están consumiendo determinado video son de Asia, Azure puede mover ese blob a un CDN de Asia para mejorar el rendimiento. Esta opción hay que habilitarla específicamente.

25 Windows Azure Storage Drives Page Blobs formateados como VHDs en NTFS
El VHD puede ser montado para lectura por varios roles o para lectura/escritura por un solo rol  Se monta en las VMs de esos roles Útil para aplicaciones legacy que necesitan un sistema de ficheros clásico debajo al que acceden con librerías de I/O Este tipo de almacenamiento sirve para montar una unidad C:/ virtual de manera que una aplicación legacy que tengamos ejecutándose en un web role determinado y que necesita acceder al sistema de ficheros para buscar unos determinados archivos, por ejemplo la aplicación de la AEAT, que si la movemos de directorio no funciona, pues con un almacenamiento tipo Drive se solucionaría. Podríamos hacer ver a una instancia determinada de un rol determinado que tiene montado un sistema de ficheros NTFS accesible a través de la unidad Ese almacenamiento VHD se monta dentro de la instancia del rol que queremos que pueda accederlo, luego ese VHD está realmente tirando de un Page externo, en el almacenamiento.

26 Windows Azure Storage Tables
Son tablas muy diferentes a las de SQL Server, no proporcionan almacenamiento relacional, es decir, no hay relaciones entre las tablas,, etc. integridad referencial Proporcionan almacenamiento estructurado no relacional super escalable. Las tablas están relacionadas con una cuenta de almacenamiento, como los blobs. Las entidades almacenadas en una misma tabla pueden tener diferentes campos (propiedades) de diferente tipo, algo impensable en almacenamiento relacional. Se utiliza un control de concurrencia optimista basado en un campo de timestamp para las actualizaciones y borrados. Explicar control de acceso optimista.

27 Windows Azure Storage Tables
Las entidades tienen siempre 3 propiedades por defecto: PartitionKey RowKey LastUpdate (controlada por el sistema) PartitionKey y RowKey identifican a una entidad unívocamente. LastUpdate se usa para el control de concurrencia PartitionKey se usa para escalar tablas  Puede llegarse a particionar una tabla en miles de nodos si hay datos suficientes Se soportan transacciones sólo para la misma partición y la misma tabla. Los datos de una transacción serán como máximo de 4 MB. Se puede acceder a las tablas mediante WCF Data Services o via una API Rest

28 Windows Azure Storage Queues
Tienen un propósito diferente a las Blobs y Tables, no proporcionan almacenamiento sino un mecanismo de comunicación entre roles, como las colas MSMQ permiten comunicación entre procesos. Explicar un poco comunicación entre procesos: memoria compartida, sockets TCP/IP, MSMQ, señales, etc. Su propósito principal es permitir la comunicación entre un Web Role y un Worker Role, proveyendo de un sistema persistente y asíncrono de paso de mensajes. Los mensajes pueden tener como máximo 8 KB. Se pueden hacer las operaciones típicas de una cola, escribir y leer un mensaje, etc.

29 SQL Azure Es la BBDD relacional (RDBMS) de Azure  Buena noticia: todo lo que sabes de SQL Server lo puedes usar en SQL Azure Básicamente es SQL Server en la nube, proporciona todo lo que conocemos: Almacenamiento relacional en tablas y vistas Índices Procedimientos almacenados Funciones Triggers

30 SQL Azure Se puede conectar con SQL Azure de igual manera que con SQL Server: ADO.NET, ODBC, LINQ, EF, PHP, etc. Se accede mediante TDS (Tabular Data Stream) sobre TCP/IP, como con un SQL Server local Esencialmente mover una BBDD a la nube y conectar con ella es cambiar la connection string Accesible mediante las herramientas de siempre: SQL Server Management Studio e incluso Reporting Services Code near: Aplicación en Windows Azure que accede a una BBBD en SQL Azure Code far: Aplicación on-premise que accede a una BBDD en SQL Azure Tres tamaños de BBDD: 1 GB, 10 GB y 50 GB Con una cuenta de SQL Azure se pueden tener N servidores lógicos, cada uno con N BBDD

31 Precios y estimación de costes

32 Precios y estimación de costes
Busquen ofertas, hay ofertas, búsquenlas en la web.

33 Precios y estimación de costes
Calculadora de ROI: Calculadora de TCO (Total Cost of Ownership): Compara el costo de un sistema on-premise con el de un sistema cloud

34 ¡Gracias! Alberto Díaz José Fortes
geeks.ms/blogs/adiazmartin geeks.ms/blogs/jfortes twitter.com/adiazcan twitter.com/jose___fortes


Descargar ppt "Cloud Computing con Microsoft Windows Azure"

Presentaciones similares


Anuncios Google