Cloudiquity

Es una gran enthusing acerca de los beneficios de la computación nube, pero ¿cuáles son las consecuencias cuando va mal? Por supuesto, hay diferentes niveles de «mal». A menudo hemos publicidad cortes de los gustos de Amazon y Google, pero dada la publicidad del SLA de cada unos es tiempo de espera. Sin embargo las cosas pueden llegar mucho más grave que esto. En el último par de días que ha surgido que Carbonite habían perdido algunos de sus clientes de datos en 2007. Según TechCrunch Carbonite perdido los datos de 7500 + clientes que dependían de la empresa para mantener sus archivos seguros. Esta surgió debido a una demanda que Carbonite presentó a los proveedores de su infraestructura. El CEO de Carbonite ofrece más detalles:

"Los fracasos de la promesa equipo se produjo principalmente durante el año 2007. Nos dejaron de comprar la promesa de conmutación de los servidores y proveedores. Nos afirman que la promesa había servidores firmware defectuoso y no lo suficientemente fiable para el uso Carbonite. Nos exigen que nos promesa de compensar por el costo de la sustitución de sus productos defectuosos. En cuanto a los 7.500 clientes afectados, sus copias de seguridad se reinicia automáticamente y de inmediato en nuestros nuevos servidores ".

En este caso parece que la pérdida de datos no tuvo ningún efecto y ninguna pérdida de datos fue mitigado por las empresas los procedimientos de seguridad interna. Sin embargo, en el caso de JournalSpace, lamentablemente este no era el caso. JournalSpace era una plataforma de blogs que han sido de alrededor de unos 6 años y, debido a un empleado disgustado, todos los clientes los blogs han desaparecido de sus servidores internos. ¡Ay!

Esta no es la primera vez que un error humano ha dado lugar a este tipo de problemas. En agosto de 2008 Plataforma FlexiScale Nube, tenía un corte de 2 días más debido a un ingeniero de eliminar accidentalmente un volumen de almacenamiento principal.

También el daño causado no sólo para el cliente, sino también a la reputación del vendedor, especialmente cuando se trate de un menor de proveedores tratando de hacer un nombre por sí mismos. Uno de esos, literalmente, la catástrofe puede ser la diferencia entre el éxito y el fracaso en el mercado.

¿Qué podemos aprender de esto? Bueno lo primero es que, al igual que la Ley de Murphy, si algo puede salir mal en algún momento tendrá invariablemente. Con esto en mente siempre debe tomar todas las medidas necesarias para proteger sus aplicaciones y datos. Esto podría significar el apoyo de ellos a nivel local o de mantenimiento de las copias de seguridad en diferentes nubes de almacenamiento y tener listo un plan de DR en su lugar. Si no, entonces no podemos culpar a la nube ....

Etiquetas: Amazonas, Carbonite, FlexiScale, Google, JournalSpace

Una encuesta a más de LinkedIn es hacer la pregunta "¿Cuáles son las áreas de Computación de Nube más preocupaciones usted o su organización". La situación actual de la encuesta es el siguiente:

Me sorprende que la seguridad está llegando es tan baja y los resultados se percibe como la preocupación número uno, será interesante para supervisar cómo los cambios en esta encuesta son más los votos emitidos. Usted puede elegir a votar aquí.

Etiquetas: Computación Nube, LinkedIn, Encuesta

La respuesta es muy sencilla 4643.

Amazon ha anunciado recientemente nuevas opciones de fijación de precios en el que reserva un ejemplo de uno o tres años y luego han de descuento sobre la tarifa por hora. El siguiente cuadro muestra el costo por año, si el ejemplo es para todo el año.

Estos precios se calcularon usando Linux ejemplo, Estados Unidos y los precios

Coste / Año On Demand ejemplo $ = coste por hora * 365 * 24

Coste / Año por 1 año Reservados ejemplo = $ 1 año precio reserva + (costo por hora * 365 * 24)

Coste / año durante 3 Año reservados ejemplo = $ (precio mínimo de 3 años / 3) + (costo por hora * 365 * 24)

Ahora esto trae cuando la pregunta interesante es rentable reserva un ejemplo?

Podemos calcular el mínimo de horas de uso sobre los que el precio más barato por hora para un ejemplo reservados comienza a disminuir el coste total mediante la siguiente fórmula

Instancia Reserva Precio / (On Demand Instancia hora Precio - Reserva Instancia Precio por hora)

por ejemplo, para un año un pequeño ejemplo reservados

350 / (0,10 - 0,03) = 4642,8 horas

3 años para las pequeñas reservados ejemplo

500 / (0,10 - 0,03) = 7142,8 horas

Las cifras son calculadas mismo ejemplo para todos los tipos. Por lo que debe reservar un año de ejemplo, si usted tiene la intención de utilizar más de 4643 horas o de la instancia es el 53% de las veces en un año. 3 años con un reservados ejemplo puede guardar el dinero en caso de más de 3 años que utiliza 7143 o más horas o el ejemplo es un 27% del tiempo durante un período de tiempo 3 años.

Etiquetas: Amazonas, EC2 precios, Reservados Instancia

Wayne Horkan tiene un buen puesto centrado en un diagrama que se utiliza para centrar el debate de Computación Nube de etiquetas que el modelo de Relación con las nubes. Me gusta en especial que cubre toda la pila, y se encontró todo un buen puesto de introducción exhaustiva a cualquier persona interesada en saber más sobre las nubes Informática.

Etiquetas: Nube, Domingo, Wayne Horkan

CloudSim se propone como un marco para la modelización y simulación de ambientes de computación de Nubes para apoyar la evaluación del desempeño de las políticas de dotación de recursos o de la solicitud de la programación y políticas de la federación de las nubes (en una forma repetible y controlable). Para obtener más información, por favor visite su Informe Técnico (PDF).

Etiquetas: CloudSim

Almacenamiento de bloques elásticos Amazonas (Amazon EBS) es un nuevo tipo de almacenamiento diseñado específicamente para Amazon EC2 casos. Amazon EBS le permite crear volúmenes que se pueden montar los dispositivos como por las instancias EC2. Amazon EBS volúmenes se comportan como si se tratara de materias primas sin discos duros externos y pueden ser formateados con un sistema de archivos como ext3 (Linux) o NTFS (Windows) y montado en una instancia EC2; archivos se accede mediante el sistema de archivos. Se han suministrado los nombres de dispositivo de usuario y proporcionar una interfaz de dispositivo de bloque.

Para un volumen de 20 GB, Amazon estima una tasa de fracaso anual de los volúmenes de EBS 1-en-200 a 1-en-1000. La tasa de fracaso aumenta a medida que el tamaño de los aumentos de volumen. Por lo tanto, ya sea una necesidad de mantener actualizada imagen de S3, o tener una copia de seguridad del contenido en otro lugar que pueda restaurar la rapidez suficiente para satisfacer sus necesidades en caso de un fracaso.

EBS cuentas puede tener un máximo de 20 volúmenes a menos que un límite superior, se pide a la Amazonía. El tamaño máximo de un volumen es de 1 TB y el almacenamiento en un volumen se limita a la provisión de tamaño y no se puede cambiar. EBS volúmenes sólo se puede acceder desde un EC2 ejemplo, en la misma zona que la disponibilidad de instantáneas S3 se puede acceder desde cualquier la disponibilidad de la zona.

Amazon S3 proporciona una sencilla interfaz de servicios web que pueden ser utilizados para almacenar y recuperar cualquier cantidad de datos, en cualquier momento, desde cualquier lugar de la web. Es para cualquier desarrollador acceder a los mismos altamente escalable, fiable, rápido, de bajo costo de infraestructura de almacenamiento de datos que Amazon utiliza para ejecutar su propia red mundial de sitios web. El servicio tiene como objetivo maximizar los beneficios de escala y pasar a los beneficios a los desarrolladores. S3 necesidades de software para poder leer y escribir archivos, pero es muy escalable, tiendas de 6 copias de datos para la HA y redundancia, y se rumorea que ser escrita en Erlang y es muy escalable.

S3 de cuentas puede tener un máximo de 100 segmentos, cada uno con almacenamiento ilimitado y un número ilimitado de archivos. El tamaño máximo de un único archivo es de 5 GB.

S3 está sujeta a "la coherencia posible", lo que significa que puede haber un retraso en escrituras que aparecen en el sistema de EBS mientras que la coherencia no tiene retrasos. EBS también sólo se puede acceder por una máquina en un momento en que las instantáneas pueden ser compartidas S3,

En términos de rendimiento S3 tiene la mayor latencia, y también tiene mayor variación en la latencia. S3 escribir latencia también puede ser superior a la lectura de latencia. EBS, por otra parte ha de latencia más bajos con menos variación. También ha writeback caché para escribir muy baja latencia. Sin embargo ser conscientes de que el almacenamiento en caché writeback y fuera de la orden de lavado puede dar lugar a un imprevisible, ya sea del sistema de archivos o una base de datos de la corrupción

En términos de rendimiento máximo rendimiento ha S3 (solo roscados), de aproximadamente 20 MB / s o 25 MB / s para multihilo. Este es un pequeño ejemplo. Esto eleva a 50 MB / s en las grandes y extra grandes casos. EBS dispone de un máximo rendimiento limitado por la red, este isapproximately 25 MB / s en un pequeño ejemplo, y 50 MB / s en los grandes casos, y 100 MB / s en extra grandes casos. Tanto como S3 y EBS son los recursos compartidos están sujetos a la desaceleración en virtud de carga pesada.

Archivo de lista de S3 es lento y de búsqueda es sólo por el prefijo que ha EBS rápido listado de directorio y búsqueda. S3 es optimizar el rendimiento mediante el uso de múltiples cubos. El escribir se ha optimizado el rendimiento por escrito teclas ordenadas en orden. EBS solo volumen el rendimiento es similar a una unidad de disco con almacenamiento en caché writeback.

Existe una alternativa a EBS EC2 y para que se PersistentFS. Con PersistentFS de montar una unidad y utilizarlo como cualquier otro, pero, y aquí está la crisis, el almacenamiento del dispositivo se realizó en la práctica en muchos pedazos poco en un cubo de almacenamiento S3. PersistentFS es un producto de código cerrado sobre la base de la FUSIBLE enfoque.

S3 cuesta 15 centavos de dólar por GB para el almacenamiento realmente utilizado y el 1 por ciento SE 10000, y 1 centavo por cada 1000 PONE. EBS cuesta 10 centavos por GB y la provisión de 1 centavo por 100.000 I / O. Para una fijación de precios de PersistentFS y cómo esto se compara con tanto S3 y EBS le sugiero que lea este post en foros de la Amazonía que tal como fue anunciado por el PersistentFS equipo.

Etiquetas: EBS, Erlang, PersistentFS, s3

Después de haber hablado de Amazonas es el único juego en la ciudad pensé que sería interesante examinar Mosso y ver las ventajas y diferencias entre Mosso y Amazonas:

Desde una perspectiva de la tecnología de Mosso no proporcionan acceso a sus raíces rompe. Que ofrecen los servidores con el sistema operativo y el software pre-instalado. Mosso afirma que esto les da la capacidad para supervisar fácilmente el servicio y la escala que sea necesario que el usuario final libera de tener que preocuparse de sistema operativo, balanceo de carga, etc ¿Cómo funciona? Bueno, Mosso resumen la plataforma que está trabajando en contra. Desde una perspectiva práctica, esto significa que usted termina con un solo directorio de espacio en el que almacenar los tipos de archivo (PHP,. ROR, etc.) Si se solicita un archivo en realidad es ejecutado por la plataforma nativa. ¿Qué significa esto? Esto significa que si usted está ejecutando ASPX archivos que serán manejadas por Windows, y si está ejecutando ROR archivos que serán tratados por Linux, etc.) Si tiene combinaciones que no parecen ser entonces el apoyo que este apoyo para usted.

Esto nos lleva a un buen Mosso diferenciador que tiene más de Amazonas, su servicio de atención al cliente es de 24 * 7 a cargo de las personas al final del teléfono a diferencia de la Amazonía. Esto puede hacer un mundo de diferencia cuando en realidad tratando de conseguir algo para el trabajo y tengo que decir que su servicio de atención al cliente es excelente.

Mosso actualmente sólo ofrece acceso a su FTP casos. No PDR, SSH, etc, que por supuesto que usted obtiene con EC2 de Amazon. Sin embargo ahora, el Amazonas no ofrecer realmente nada que compita con la principal Mosso nube ofreciendo cuyo valor punto están proporcionando balanceo de carga de Windows y aplicaciones web basados en Apache, así como de semi-carga equilibrada de SQL Server y MySQL ofertas. Esto es lo Mosso llamada Nube Sitios. Automatizados de balanceo de carga viene de Amazonia, pero no está ahí todavía, y ahora hay que rodar el suyo propio.

No existe el concepto de compartir la imagen con Mosso casos como el concepto básico es diferente ieyou no están funcionando con 1 "virtuales" son ejemplo pero realmente trabajan con una interfaz que funciona como un tipo de fascade a un potencialmente muchos casos. Dicho esto, Mosso actualmente pruebas beta son algo que se llama "nube de servidores" y parece que esta será la competencia directa a EC2.
Actualizado: Mosso Nube Servidores ahora va en directo el 16 de marzo. Los precios comienzan en $ 0.015/hour o $ 10.95/month. Consulte los detalles aquí. También tendrán una API. Para ver un adelanto en la API de correo electrónico Mosso y preguntar. Nube de archivos también está fuera de beta el 12 de marzo de 2009. Archivos de la nube es Mosso de almacenamiento en línea y servicio CDN permitido servir contenido estático motor. Tiene varias funciones nuevas. Consulta todos los detalles aquí.

Amazon tiene un montón de servicios adicionales que ofrecen para interactuar con los núcleos de los casos, como S3, SimpleDb, SQS, CloudFront etc, y que ha Mosso Nubes archivos no tiene la amplitud o extensión de los servicios que proporcionan Amazonas.

Otra diferencia es la facturación de servicios. Ahora Amazon no proporcionan copia de facturas de facturación (un error en particular la elaboración del Amazonas foros) que impide a muchas organizaciones de la Amazonía que utilizan, mientras que proporcionan este Mosso.

En conjunto, Mosso es una buena solución de alojamiento de nubes. Es propuesta de valor es diferente de EC2 Amazonas y que tiene más potencia y flexibilidad es, sin duda, existe espacio para el servicio Mosso prevé que pueda llegar a muchas personas en marcha más rápido. Carece de la capacidad de tener pre-configurado AMI casos, por lo que no será capaz de obtener una pre-instalado y configurado Hadoop ejemplo, o lo que sea, que para algunos es uno de los atractivos de EC2, pero para poder rápidamente haber configurado las aplicaciones Web y balanceo de carga es perfecta.

Comercialmente no se desprende la utilidad de calcular granular modelo que ofrece Amazon, ya que ha de arranque tanto alzado de 100 dólares por mes. Esto incluye 50 GB de espacio de almacenamiento, 500 GB de ancho de banda mensual, 10000 calcular los ciclos, y 24 * 7 * 365 de apoyo de chat en vivo.

Así que en resumen ha Mosso únicas diferenciadores:

- Los diferentes modelos que permite una rápida configuración y balanceo de carga de aplicaciones web

- 24 * 7 * 365 de apoyo en vivo

- Copia impresa facturas

La forma en que se dirige Mosso que proporciona un buen conjunto de características diferentes, así como algunas ofertas comparables en la tubería que debe garantizar la Amazonía no tienen todo a su manera.

Etiquetas: Archivos de nubes, nubes de servidores, sitios de nubes, Mosso

Simone Brunozzi, evangelista de tecnología AWS, en Europa, envió algunas otras historias de éxito / casos de uso de Amazon Web Services en Europa y Asia en el Amazonas blog - He reposted a continuación el artículo, ya que siempre hace la lectura interesante para ver cómo las empresas están adoptando nube de computación y, en particular, los detalles son lo que el uso de caso.

Industria, Islandia

Industria de la misión es mejorar la experiencia de ver TV.

Industria aprobó el Amazon Web Services para su ZignalCloud servicio, así como para la prestación de servicios de entretenimiento digital Zignal plataforma. Nube Zignal reduce el coste total de propiedad de los prestadores de servicios y proporciona la previsibilidad de los costos, la tecnología reduce los riesgos y reduce los plazos de comercialización.
En su blog, su estado:
"Una consecuencia de la intención de este enfoque es que podemos hacerlo todo por adelantado, sin coste para nuestros clientes, porque estamos utilizando de manera efectiva un verdadero modelo de participación en los gastos que nos ofrece casi un 100% de la economía de escala".

Por supuesto, cuando se utiliza Amazon Web Services, se le cobrará sólo por lo que usa, sin inversión inicial. Puede leer más detalles sobre las ofertas de AWS en nuestra página de producto.

Si estás interesado en ZignalCloud, puede contactar Industria en Islandia, Irlanda, Bulgaria, Reino Unido, Suecia o China.

Cuando empezaron a imageloop.com 's transición a Amazon Web Services, que necesitan para convertir todas sus fotos antiguas, la generación de nuevas imágenes y formatos de salida.

Que normalmente habría tomado meses, pero ya que había un acceso prácticamente ilimitado a energía de la cpu con EC2, que acaba de lanzarse c1.xlarge sesenta casos que fuera alimentado SQS conversión de puestos de trabajo y se realizaron en un día y medio.

Luego, una semana más tarde, cuando iban en vivo, se prevé una noche de mantenimiento de inactividad, y convertido las imágenes que se habían acumulado durante la semana, alrededor de 110.000 imágenes, utilizando EC2 diez casos durante dos horas.

En general, imageloop.com está muy satisfecha con el nivel de flexibilidad que ofrece Amazon.

De las palabras de Antonio: "la velocidad de entrega de los pases de diapositivas es mucho mejor que antes y nos gustó la flexibilidad y la facilidad con la que hemos sido capaces de construir la plataforma. Felicidades a un gran producto! "

Y esto es Stefan Riehl, imageloop.com 's CEO: "Cuando comenzamos la evaluación de alternativas de alojamiento a los proveedores, se hizo evidente que la oferta de AWS es el más maduro en el mercado."

SnappyFingers es una pregunta y respuesta del motor de búsqueda. SnappyFingers rastrea e indexa Preguntas más frecuentes sobre la Internet, y proporciona resultados de búsqueda en un fácil para ver Avatar de formato.
Chirayu Patel tuvo la amabilidad de compartir con nosotros algunos detalles sobre cómo utilizar Amazon Web Services (AWS), junto con algunos motivos de sus decisiones.

Los tres principales motivaciones de sus decisiones son (en sus propias palabras):
- Que son extremadamente reacios a aprender o hacer algo fuera de SnappyFingers dominio. Preferiríamos externalizar.
- Estamos muy conscientes de los costos.
- No escriba con errores de código, pero no queremos que nuestros sistemas de morir debido a ella.

Durante el diseño de SnappyFingers, consideraron varias opciones, pero al final se escogió Amazon Web Services.
Análisis de costos preliminares mostraron que el costo básico de la AWS alternativas sería menor en el largo plazo. También, hubo una ventaja de no depender de un solo proveedor. Sin embargo, una vez que se añaden los gastos de la gestión de los sistemas, la ventaja financiera de la utilización de AWS, se hizo evidente.
Esto, junto con el hecho de que no quieren que se distraiga con las cargas operacionales no vinculados a su actividad principal, significa que AWS se convirtió en la opción obvia para la ampliación de CPU / recursos de almacenamiento.
SnappyFingers Arquitectura
SnappyFingers se compone de dos sistemas - un sitio web, y sistema de recuperación de información (IRS). El sitio web corresponde al sistema que sirve a las peticiones de usuario, y el IRS es el sistema que hace todo el trabajo detrás del escenario para recoger Q & A.
SnappyFingers es principalmente codificados en Python, Java idiomas, y usos múltiples paquetes de terceros: en particular, siendo el marco Django, multiprocesamiento paquete en Python y Apache Lucene, un alto rendimiento, completamente equipado de la biblioteca de motores de búsqueda de texto escrito íntegramente en Java.

El sitio Web se ejecuta en al menos tres nodos EC2, y utiliza los siguientes componentes.
1. Nginx - Un servidor web extremadamente rápido, que se utiliza para servir estático / contenido de cache. También se utiliza para el tráfico de proxy inverso a múltiples servidores Apache.
2. Servidor Apache con mod_python para ejecutar el código Python junto con el marco Django.
3. Los usuarios a realizar búsquedas en el el Q & A índice.
4. Deletrear damas.
5. PostgreSQL, para la gestión del sistema: los errores de grabación, registro de nuevos servicios, y tal.

Caching está incorporada en el sistema usando una combinación de memcached y el sistema de archivos de caché. Contenido se sirve mediante la Amazonía CloudFront. Amazonas mecánico turco se utiliza para probar la relevancia de los resultados de búsqueda.
El Sistema de Recuperación de Información (IRS) es responsable de la creación de Q & A de índices que se utilizarán por los usuarios. Utiliza múltiples servicios para hacer el trabajo:
1. Rastreadores para rastrear la Internet.
2. Analizadores para extraer Preguntas y respuestas de cada página, detectar el spam, y eliminar el contenido duplicado.
3. Anotadores para anotar el Q & A sobre la base de una serie de factores. Los algoritmos de puntuación son los más dinámicos de piezas de código, y están en continua evolución.
4. Indizadores al índice el Q & A.
Estos servicios interactuar con múltiples dispositivos de almacenamiento - Amazon S3, Amazon SimpleDB y Postgresql. No todos los datos se almacenan en todos los lugares. Basado en el tamaño de los datos, requisitos y recuperación, almacenamos los datos en diferentes lugares. Todos los datos de acceso se realiza a través de una costumbre basada en Python ORM (Mapeo Objeto Relacional) para simplificar la programación.

Otro aspecto de estos servicios es que se pueden ejecutar en cualquier nodo. A veces han utilizado una determinada cantidad de EC2 servidores, mientras que en otros, han reducido su infraestructura en función de la carga y su presupuesto mensual AWS.
En la actualidad, el IRS ha consumido aproximadamente 500 GBytes por un conjunto de datos de 11 millones de Q & A.
Intracomunitario de servicios de comunicación utiliza el concepto de tuberías, cada una con su propio conjunto de tuberías. Cada tubo (Amazon SQS cola) es propiedad de un servicio, que es responsable de la tramitación de los mensajes dentro de ella. Una vez completado el procesamiento de mensajes son enviados a la siguiente tubería en la tubería.

Esta arquitectura no sólo ha permitido mantener SnappyFingers a la naturaleza modular del sistema, sino también para desarrollar y desplegar servicios de forma aislada con el resto del sistema.

Tratamiento de errores de la estrategia es simple: en un error, un servicio de registro de error y guardar el mensaje correspondiente en la Amazonía SimpleDB, y seguir procesando el siguiente mensaje. El servicio se detiene sólo cuando la tasa de error es superior a los umbrales configurado.
Una vez que los errores han sido corregidos, los mensajes son empujados de nuevo a Amazon SQS para la finalización del tratamiento.
Utilización de la CPU y la ampliación
Todos los servicios del IRS están diseñados para mantener la ocupación del 100% de CPU (o configurado a un valor), usando Python multiproceso del paquete para desovar / matar los procesos para mantener la ocupación de la CPU.
Los servicios son independientes de los nodos en los que se están ejecutando, y si hay un enorme retraso de los mensajes en Amazon SQS, EC2 más nodos pueden ser generado para gestionar la carga adicional.

Etiquetas: Amazon Web Services, Computación Nube, imagelooop, industria, IRS, simon brunozzi, snappyfingers, casos de uso

Vemos estas preguntas una y otra vez - "¿Cómo el diseño para la carga de pico" y "¿Cómo se escala en la nube?". En primer lugar permite averiguar la manera de dar una definición de pico de carga:

Haremos una puñalada en la definición de pico de carga, tal como: "Un porcentaje de la actividad en un día / semana / mes / año que viene dentro de una ventana de unas horas y se considera como extremo y se produce debido a la estacionalidad o bien a causa de los picos impredecibles ".

El Thomas Consulting Group tiene una buena puñalada (ppt) a un forumla para tratar de predecir y planificar para el pico de carga. Su fórmula y el ejemplo se muestra a continuación:

H = pico de visitas por segundo
h = # de visitas recibidas durante un período de un mes
a =% de la actividad que viene durante la hora punta
t = tiempo en horas pico
entonces
H = h * a (días laborables * t * minutos * segundos)
H = h * a / (108.000 * t)

Determinar el pico de usuarios virtuales: Pico visitas / segundo + página vista veces

U = pico usuarios virtuales
H = pico de visitas por segundo
p = número promedio de visitas / página
v = promedio de tiempo que un usuario visualiza una página

U = (H / p) * v

Ejemplo:

h = 150.000.000 visitas al mes
a = 10% del tráfico se produce durante la hora punta
t = tiempo máximo es de 2 horas
p = una página consta de 6 visitas
v = la media de opinión de tiempo es de 30 segundos

H = (h X a) / (108.000 * t)
H = (150.000.000 * .1) / (108.000 X 2)
H = 48

U = (H / p) * v
U = (48 / 6) * 30
U = 8 * 30
U = 240

Deseado Métrico - 48 Hits / Sec o 240 usuarios virtuales

En el ejemplo de Thomas Consultoría pico por encima de la carga actual es 15.000 visitas en dos horas mientras que el promedio normal de visitas de dos horas es 411 [(((H * 12) / 365) / 24) * 2]. Esto es más un aumento del 70% y una diferencia enorme, y este ejemplo no es extrema. Web en línea del consumidor las empresas pueden hacer el 70% de su negocio anual en diciembre solo.

Dependiendo de la que más se produce durante el transactionality de los éxitos, entonces esta puede ser la diferencia entre tener 1 EC2 instancia y que tienen más de 10, o una diferencia de costo entre $ 6912 a $ 82.944 en el curso de un año (basado en un gran ejemplo Amazon EC2) . Y, por supuesto, para la construcción de lo que piensas es pico todavía puede dar lugar a problemas. Una famosa cita de Scott Gulbransen de Intuit es:

"Cada año, tomamos la actividad minuto de la hora de mayor actividad el día y desarrollar la capacidad de que, Construimos nuestros sistemas (que manejan la carga) y nos fuimos por encima y más allá." A pesar de ello los sistemas que todavía no puede manejar la carga.

Lo que realmente queremos ser capaces de hacer es tener nuestro sitio para construir nuestra carga media, con exclusión de pico, y la escala en la demanda han incorporado en la arquitectura. Como EC2 es el más maduro nube plataforma veremos herramientas que pueden lograr esto en EC2:

GigaSpaces XAP: Desde la versión 6.6 de la Plataforma GigaSpaces XAP Nube herramientas se construye en. GigaSpaces es la siguiente generación de plataforma middleware virtualizado que aloja la lógica, datos y mensajes en memoria, y tiene menos partes móviles, para que la ampliación puede ser alcanzado linealmente , a diferencia de las plataformas tradicionales middlware. GigaSpaces nos respaldados por un servicio de red que permite a nivel de aplicación del Acuerdo de Nivel de Servicio que se establezcan y que sean objeto de control y ha actuado en tiempo real. Esto significa que si la carga se incrementa luego GigaSpaces puede hilos escala o el número de casos middlware virtualizado para garantizar que se cumple el SLA, que en nuestro ejemplo sería la capacidad de acción de procesar el número de solicitudes. GigaSpaces también asociado con RightScale. GigaSpaces le permite probar su oferta Nubes gratis antes de seguir el tradicional modelo de utilidad calcular los precios.

Scalr: Scalr es una serie de máquinas de imágenes de la Amazonia (IAM), para el sitio web de necesidades básicas, es decir, una aplicación de servidor, un balanceador de carga, y un servidor de base de datos. La AMIS son pre-construida con una suite de gestión que supervisa la carga de funcionamiento y el estado de los diferentes servidores de la nube. Scalr con objeto de aumentar o disminuir la capacidad de la demanda fluctúa, así como la detección y la reconstrucción de los casos incorrectamente funcionamiento. Scalr de código abierto y tiene versiones comerciales y es un relativamente nuevo servicio de infraestructura o de la solicitud. Nos gustó la de la 'Sincronizar a todos »características de Scalr. Esto incluye un auto-AMI y volver a despliega en una nueva instancia. Hace esto sin interrumpir el funcionamiento básico de su sitio. Esto ahorra tiempo pasa a través de la imagen EC2 / AMI proceso de creación. Para saber más sobre Scalr deberá verificar la Scalr foro de Grupos de Google.

RightScale: RightScale posee una plataforma de gestión automatizada de nubes. RightScale servicios incluyen la ampliación automática de los servidores de acuerdo con el uso de carga, y pre-construido para la instalación de las plantillas de las pilas comunes de software. RightScale apoyo Amazon EC2, Eucalipto, FlexiScale, y GoGrid. Que se cotizan como diciendo que RackSpace apoyo también va a pasar en algún momento. RightScale tiene un gran oveview estudio de caso en su blog acerca de Animoto y también se explica cómo se han puesto en marcha, configurado y gestionado más de 200, oo0 casos hasta la fecha. RightScale son respaldados VC y en diciembre de 2008 hizo un $ 13 millones de serie B ronda de financiación. RightScale tienen libre y ofertas comerciales.

FreedomOSS: Libertad OSS ha creado plantillas personalizadas, llamado jPaaS (JBoss Plataforma como servicio), para ampliar los recursos, como JBoss Application Server, JBoss Mensajes, Reglas de JBoss, jBPM, Hibernate y JBoss Costura. jPaaS supervisa la carga de casos y escalas según sea necesario. jPaaS se encarga de la actualización de la vhosts archivo y otros archivos de configuración para asegurarse de que todos los casos de Apache responder a este nombre de host. El recién desplegados aplicación que se ejecuta, ya sea en Tomcat o JBoss se convierte en parte de la nueva imagen de servidor de aplicaciones.

Etiquetas: nubes, nubes de computación, GigaSpaces, carga pico, pico de carga de provisiones, RightScale, Scalr

iPhone Application "Nube de estado le permite supervisar el estado de cualquiera de Google App. motor, Amazon Web Services, y Twitter en tiempo real. Es un ejemplo simple pero eficaz de seguimiento y como servicio. Está disponible a partir de Industrias Ligeras Bablim en el iPhone App. tienda.

Etiquetas: Nube Estado, motor de Google App., iPhone, Vigilancia, Twitter